Small problem with self-compiled x64 version
- Author
- Message
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
Small problem with self-compiled x64 version
(Disclaimer: I am describing a problem that doesn't happen with the released AP version.)
I am compiling a patched version of AP with various extensions (support for multiple INI files, wildcard command line arguments etc). Until now I've always compiled the patched sources to 32 bit (ie x86) and everything (including my extensions) works very well.
I've now tested the x64 waters with my currently installed 4.8.9 sources by compiling them to 64 bit. This version mostly works but there's one strange problem to do with the script engine.
The effect is this: I am analysing command line filename arguments and if I find an argument containing * or ? I then call a .js script with that argument to open the wildcarded files. This code has worked for years in the 32-bit executable.
Well, with the 64-bit executable it doesn't work. I've tried to debug the problem and it seems that the script engine is simply not yet ready at the point in time when I call Script::Main. If I include a simple message loop for half a second before actually calling the script engine, everything works as it should.
Is there a way to control the loading of plugin DLLs? Or does anyone have another idea how I can get rid of that message loop? (This is only a small annoyance but I'd like to know why it doesn't work and, if possible, avoid that message loop hack.)
THX TM
I am compiling a patched version of AP with various extensions (support for multiple INI files, wildcard command line arguments etc). Until now I've always compiled the patched sources to 32 bit (ie x86) and everything (including my extensions) works very well.
I've now tested the x64 waters with my currently installed 4.8.9 sources by compiling them to 64 bit. This version mostly works but there's one strange problem to do with the script engine.
The effect is this: I am analysing command line filename arguments and if I find an argument containing * or ? I then call a .js script with that argument to open the wildcarded files. This code has worked for years in the 32-bit executable.
Well, with the 64-bit executable it doesn't work. I've tried to debug the problem and it seems that the script engine is simply not yet ready at the point in time when I call Script::Main. If I include a simple message loop for half a second before actually calling the script engine, everything works as it should.
Is there a way to control the loading of plugin DLLs? Or does anyone have another idea how I can get rid of that message loop? (This is only a small annoyance but I'd like to know why it doesn't work and, if possible, avoid that message loop hack.)
THX TM
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
Thanks for looking into this, I really appreciate that.
I've always assumed this simply works. And it always did... for the 32-bit version. Strange that it should break with the 64-bit version.
Any other ideas?
That's what I tried first but alas, it didn't work. As I am simply replacing an existing command line argument (let's say "*.c") with an argument calling the script engine like thisInstructor wrote:tmsg?Scripts-Eng.txt wrote:Call("Scripts::Main", 2, "SCRIPT", "ARGUMENTS")
Same as previous, but wait for script completion.
Code: Select all
if (xstrstrW(wszCmdArg,-1,L"*",1,0,NULL,NULL)||xstrstrW(wszCmdArg,-1,L"?",1,0,NULL,NULL)) { // TM!!!
GetFullName(wszCmdArg,wbuf2,BUFFER_SIZE,NULL);
xprintfW(wszCmdArg,L"/Call("Scripts::Main",1,"openWildcard.js",`"%s"`)",wbuf2);
WaitForScriptPlugin(); // This is new; it simply executes a message loop for 500 msec.
goto DoExtActCall;
Any other ideas?
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
I copied this code excerpt verbatim from my current version of Edit.c in which I have long reverted to "1" since "2" made no difference whatsoever.Instructor wrote:tmsg
Your code example not contain external call 2. Do you sure you are calling?/Call("Scripts::Main", 2
Indeed, the first thing I did when I found that the 64-bit version didn't work, even before I realised that it seems to be a timing problem, even before posting here, was testing that call with a value of 2. It just didn't work... if it had, I'd not posted here.
[EDIT]So, to be perfectly clear: the code shown above, with that call to a message loop, does work. But code w/o calling the loop but with a parameter of "2" doesn't.[/EDIT]
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
I already do that (ie no processing of my extensions if nType==PCL_ONLOAD) because my code is inserted directly after the lastInstructor wrote:Make sure that your code not processed when type of ParseCmdLine is PCL_ONLOAD.
Code: Select all
if (nType == PCL_ONLOAD) return PCLE_ONLOAD;
// ... my extensionshere
It's all very strange...
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
See sources (.7z file) in http://www30.zippyshare.com/v/6808995/file.htmlInstructor wrote:tmsg
Upload Edit.c and openWildcard.js.
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
Thank you. Take your time... I do have a version up and running that's working so there's no pressing need although I am definitely curious as to why the code works in 32 bit and doesn't in 64 bit...Instructor wrote:tmsg
Visually don't see any problems. I will try to check it on next week when I get access to x64 OS.
(Note: The main reason why I want(ed) to switch from 32 bit to 64 bit is that the 32 bit version doesn't see the \Windows directory tree correctly (system32 vs SysWOW64 etc).)
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
tmsg
There is topic in MSDN "File System Redirector" and some usefull functions
Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection, Wow64EnableWow64FsRedirection. You can try them in your patch. Maybe having successful experience(since has access fro x64 PC rarely) Instructor will incorporate it into base.
Yes, it is another MS idiotic bug-feature. Real %Systemroot%\System32 directory is visible for 32bit application under %Systemroot%\sysnative, etc(Note: The main reason why I want(ed) to switch from 32 bit to 64 bit is that the 32 bit version doesn't see the \Windows directory tree correctly (system32 vs SysWOW64 etc).)
There is topic in MSDN "File System Redirector" and some usefull functions
Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection, Wow64EnableWow64FsRedirection. You can try them in your patch. Maybe having successful experience(since has access fro x64 PC rarely) Instructor will incorporate it into base.
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
I first thought about that option as I've done exactly this for a couple of other, smaller utilities I've written myself.FeyFre wrote:tmsgYes, it is another MS idiotic bug-feature. Real %Systemroot%\System32 directory is visible for 32bit application under %Systemroot%\sysnative, etc(Note: The main reason why I want(ed) to switch from 32 bit to 64 bit is that the 32 bit version doesn't see the \Windows directory tree correctly (system32 vs SysWOW64 etc).)
There is topic in MSDN "File System Redirector" and some usefull functions
Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection, Wow64EnableWow64FsRedirection. You can try them in your patch. Maybe having successful experience(since has access fro x64 PC rarely) Instructor will incorporate it into base.
However, using those functions from within AkelPad is not a good idea, IMHO. First of all, they only work on a per-thread basis. Second, once redirection is switched off for a thread this applies to all further disk accesses this thread performs. This means, among other things, that such a thread can't reliably load any further system DLLs or other files from what it believes to be its system32 directory (ie the real SysWOW64) because this is now pointing to the 64-bit version (ie the real system32).
-
Offline
- Site Admin
- Posts: 6311
- Joined: Thu Jul 06, 2006 7:20 am
tmsg
I have tried your attachment on Win7 x64 - all works fine without "WaitForScriptPlugin".
Executed:
Maybe you have some antivirus that locked dll loading on start?
I have tried your attachment on Win7 x64 - all works fine without "WaitForScriptPlugin".
Executed:
Code: Select all
AkelPad.exe "e:\Installs\VC++\AkelPad-4.9.1\*.txt"
-
Offline
- Posts: 60
- Joined: Tue Aug 21, 2012 11:17 am
- Location: UK
That's very strange... It still doesn't work here and I have no anti-virus package whatsoever.Instructor wrote:tmsg
I have tried your attachment on Win7 x64 - all works fine without "WaitForScriptPlugin".
Executed:Maybe you have some antivirus that locked dll loading on start?Code: Select all
AkelPad.exe "e:\Installs\VC++\AkelPad-4.9.1\*.txt"
I will wait for the 4.9.1 release and re-check. If it still doesn't work then, I'll have a look.