1
Vote

PDFRider compilation is not properly configured for 64-bit systems

description

On 64-bit systems, .NET JIT compiler runs in 64-bit mode when the application is compiled as processorArchitecture=msil.
 
OK, that's nice - almost "good" - for programs that are self-sustaining with no external dependencies (like a browser control), but when the program relies on external plugins inside an external container (web browser), it gets messy.
 
There is no 64-bit Adobe Reader, so since the 64-bit mode of PDF Rider opens a 64-bit Internet Explorer control, it tries to open a PDF handler that's registered only with the 64-bit version of Internet Explorer (verified by the same behavior occurring in "Internet Explorer (64-bit)").
 
The symptom this causes is that PDF Rider opens normally, but when you open a PDF, it shows that the file couldn't be opened, and it opens Adobe Reader in a new window (which is the 64-bit IE behavior).
 
Using "CorFlags.exe /32BIT+ PdfRider.exe", I was able to modify the program to explicitly run in 32-bit mode, and it works 100% perfectly with 32-bit emulation ("PDFRider.exe*32" in Task Manager).
 
Simply changing the processorArchitecture from "msil" to "x86" should correct this problem, although I'm not a .NET developer (...yet) and have no idea where that parameter would be hidden... probably somewhere in the project options. But that'll make PDFRider work with 64-bit systems, as I can 100% guarantee it's non-functional for most users right now running 64-bit Windows ;)

file attachments

comments

peterhoeg wrote Jan 18, 2012 at 3:36 PM

This patch is not build-tested as I don't have any Windows machines with Visual Studio nearby.

francescot wrote Jan 23, 2012 at 8:06 AM

This should be already fixed, but I don't have any 64-bit system to test...

FalconFour wrote Jan 23, 2012 at 9:09 AM

ಠ_ಠ

You don't have any 64-bit systems? Okay, don't take this the wrong way, but...

ಠ_ಠ

You don't have any 64-bit systems?! xD Shoot, nearly everything (all new computers) run 64-bit Windows... admittedly I'm a bit of a hypocrite right now running Win7 x86 on my main PC now (4gb RAM, 30gb SSD,, not worth the ~4-8GB extra HDD space for 64-bit components IMO), but... just LOL! :P

The general problem is that the program was compiled in a "switchable" mode that runs natively on 64-bit or 32-bit, but that causes compatibility problems with the 32-bit subsystem (WOW64) that run most programs on a 64-bit Windows PC. Kind of a convoluted, complicated system (same as way back with Windows XP x64) that only shows 64-bit programs the "real" registry, filesystem, drivers, etc., and 32-bit programs get corralled off in the SysWOW64 folder, "Program Files (x86)" folder, "HKEY_LOCAL_MACHINE\Software\WOW6432Node" registry key, etc. So if a 64-bit-mode program wants to run a 32-bit-mode program, it needs to know to translate its path accordingly (since its folder is "Program Files", and 32-bit apps are located in "Program Files (x86)", the environment variable %PROGRAMFILES% won't point it there!).

Hopefully that info helps - but really, the quickest solution (and I'm sure the one you've done already) is just to compile it as 32-bit only :)

peterhoeg wrote Feb 17, 2012 at 8:22 AM

I can confirm that v0.6.1 works on 64bit.

wrote Feb 22, 2013 at 12:53 AM