Foxit Reader has a new version out (V2.1), so I tried to build a JPE wrapper for it. But I kept getting "This file is not a valid EXE" at the end of the process.
Any ideas?
Problem with Foxit Reader V2.1
-
Andrew Lee
- Posts: 3063
- Joined: Sat Feb 04, 2006 9:19 am
- Contact:
-
Andrew Lee
- Posts: 3063
- Joined: Sat Feb 04, 2006 9:19 am
- Contact:
A little precision to what I wrote above. I don't use the command line to start. As mentioned, I use portable launcher or launchpad.
It works, but there is one little strange thing, though. Sometimes I start it and it works perfectly. Sometimes I start it and the application starts (I see it in the Task Mgr | Processes list), but no application window shows up. I can start it 5 times and will see 5 processes in Task Mgr, but no application window.
If I delete the 5 processes and restart application, sometimes it comes up as expected, but sometimes, it goes invisible again...???...???
I have used 0.1.4 with ini file. I have changed some settings in the ini file (mainly what registry keys to exclude), but nothing consistent. I have also tried the same thing with Foxit 2.0 and it shows the same sporadic behavior (that I did not notice before, hum).
Not really looking for a solution. I will continue to try to see what the problem is. I just wanted to share this strange behavior. I tried all applications that I have successfully JPE'ed and this is the only one that does this. Other applications that I am working on JPEing sometimes does this as well so this may be a multi-application (JPE) thing and not something specific to Foxit Reader.
It works, but there is one little strange thing, though. Sometimes I start it and it works perfectly. Sometimes I start it and the application starts (I see it in the Task Mgr | Processes list), but no application window shows up. I can start it 5 times and will see 5 processes in Task Mgr, but no application window.
If I delete the 5 processes and restart application, sometimes it comes up as expected, but sometimes, it goes invisible again...???...???
I have used 0.1.4 with ini file. I have changed some settings in the ini file (mainly what registry keys to exclude), but nothing consistent. I have also tried the same thing with Foxit 2.0 and it shows the same sporadic behavior (that I did not notice before, hum).
Not really looking for a solution. I will continue to try to see what the problem is. I just wanted to share this strange behavior. I tried all applications that I have successfully JPE'ed and this is the only one that does this. Other applications that I am working on JPEing sometimes does this as well so this may be a multi-application (JPE) thing and not something specific to Foxit Reader.
-
Andrew Lee
- Posts: 3063
- Joined: Sat Feb 04, 2006 9:19 am
- Contact:
-
Andrew Lee
- Posts: 3063
- Joined: Sat Feb 04, 2006 9:19 am
- Contact:
chezduong, could this behaviour you observed be related to the lack of a [RegistryIgnore] directive?
I used to encounter this problem with xplorer2lite, where it refuses to exit and pump the CPU usage up to 100%.
The reason, as redllar explained, was that xplorer2lite deletes a reg key, then checks for it again to make sure it has been deleted. If you have this reg key in the actual registry (eg. you have installed the proggie previously), the check will succeed, since the reg key was deleted from the virtual registry, but could be found in the actual registry. This trips up the program and makes it go into an infinite loop.
If a [RegistryIgnore] is included, the check will fail, since the request is not passed on to the actual registry, which is what is needed.
Just wondering whether something similar is happening that causes the window to refuse to display.
I used to encounter this problem with xplorer2lite, where it refuses to exit and pump the CPU usage up to 100%.
The reason, as redllar explained, was that xplorer2lite deletes a reg key, then checks for it again to make sure it has been deleted. If you have this reg key in the actual registry (eg. you have installed the proggie previously), the check will succeed, since the reg key was deleted from the virtual registry, but could be found in the actual registry. This trips up the program and makes it go into an infinite loop.
If a [RegistryIgnore] is included, the check will fail, since the request is not passed on to the actual registry, which is what is needed.
Just wondering whether something similar is happening that causes the window to refuse to display.
Andrew, exactly what method are you using to create the portable launcher? If you're using the command line, as Chris did, the path to the app's executable needs to be in double quotes, as "Foxit Reader.exe" has a space in it. This is kind of command line usage 101 and is not specific to JPE so I forgot to mention that in the readme.Still can't figure out why I am getting an error message when I try to generate the wrapper myself...
If you're using the JPE build wizard then you shouldn't be getting this error message at all. I tried everything I could think of to duplicate it here but I can't.
So specifics, please.
Yeah, if the cpu usage gets pegged then it's probably something like that.Andrew Lee wrote:chezduong, could this behaviour you observed be related to the lack of a [RegistryIgnore] directive?
I used to encounter this problem with xplorer2lite, where it refuses to exit and pump the CPU usage up to 100%.
The reason, as redllar explained, was that xplorer2lite deletes a reg key, then checks for it again to make sure it has been deleted. If you have this reg key in the actual registry (eg. you have installed the proggie previously), the check will succeed, since the reg key was deleted from the virtual registry, but could be found in the actual registry. This trips up the program and makes it go into an infinite loop.
If a [RegistryIgnore] is included, the check will fail, since the request is not passed on to the actual registry, which is what is needed.
Just wondering whether something similar is happening that causes the window to refuse to display.
But it could also be due to something called deadlocking. If the app is just sitting there not using up any cpu time then that's probably what's happening. The reason I suggest this is I noticed that Foxit Reader is using 2 threads, so it could be that the threads are locking each other out within the JPE dll. This would show up if you had an especially fast running setup, which chezduong might have if he's running from the RAM drive of his. I ran into a similar problem when working on portablizing SlowLearner's TWE app, which uses 8 threads. I have a jpe dll that works with it now but I need to do a lot more testing before I feel comfortable enough to release it, as the changes I made impact everything the dll does.
Sorry, I got you confused with Chris for some reason. The dead-lock condition can also occur on slow systems as well. I don't think it's as likely though since I *think* the condition occurs when one thread is working on a file system redirection while another thread is working on a registry redirection, but both threads are overlapping in the registry keys being accessed.chezduong wrote:@redllar, I have a slow setup: AMD Athlon 2000+ (1.6 Mhz), 256 Mb RAM and WinXP SP2 so it's not my "fast" setup. But you are right. Once loaded, Foxit takes up zero processor.
Anyway, if this occurs frequently enough for you, and you're willing to do some testing, it would be interesting to see what happens while changing the JPE runtime [Redirection]MemRegistry setting. Start with it equal to 0 and see if the app still hangs at close. Then try 1, 2, 3, and 4.
Here is my superscientific test. Same "speedy" test machine as above. Opened and closed app ~10 times, waiting 3-4 seconds between closing and re-opening. Changed MemRegistry setting in ini file. Saved ini file. Tested at next setting ~10 times. Come back to prior MemRegistry setting. Tested ~5 more times.
Note that launch always fails when changing from text-based .reg file to binary-based .reg file and the opposite. I did not change/delete .reg files between MemRegistry settings. I did not count failed launches in this case.
MemRegistry=0
Works nearly consistently. Has become my default setting.
MemRegistry=1
Hit or miss. No detectable pattern.
MemRegistry=2
Hit or miss. No detectable pattern.
MemRegistry=3
Works fairly consistently, but still misses about 3 out of 20 times. Startup seems faster than 0, 1 & 2.
MemRegistry=4
Hit or miss. Startup seems faster than 0, 1 & 2.
Hope this helps you. It helped me solve my Foxit Reader 2.1 problem. Cheers.
Note that launch always fails when changing from text-based .reg file to binary-based .reg file and the opposite. I did not change/delete .reg files between MemRegistry settings. I did not count failed launches in this case.
MemRegistry=0
Works nearly consistently. Has become my default setting.
MemRegistry=1
Hit or miss. No detectable pattern.
MemRegistry=2
Hit or miss. No detectable pattern.
MemRegistry=3
Works fairly consistently, but still misses about 3 out of 20 times. Startup seems faster than 0, 1 & 2.
MemRegistry=4
Hit or miss. Startup seems faster than 0, 1 & 2.
Hope this helps you. It helped me solve my Foxit Reader 2.1 problem. Cheers.