Small problem with self-compiled x64 version

English main discussion
  • Author
  • Message
Offline
Posts: 60
Joined: Tue Aug 21, 2012 11:17 am
Location: UK

Small problem with self-compiled x64 version

Post by tmsg »

(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

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

tmsg
Scripts-Eng.txt wrote:Call("Scripts::Main", 2, "SCRIPT", "ARGUMENTS")
Same as previous, but wait for script completion.
?

Offline
Posts: 60
Joined: Tue Aug 21, 2012 11:17 am
Location: UK

Post by tmsg »

Thanks for looking into this, I really appreciate that.
Instructor wrote:tmsg
Scripts-Eng.txt wrote:Call("Scripts::Main", 2, "SCRIPT", "ARGUMENTS")
Same as previous, but wait for script completion.
?
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 this

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;
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?

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

tmsg
Your code example not contain external call 2. Do you sure you are calling
/Call(\"Scripts::Main\", 2
?

Offline
Posts: 60
Joined: Tue Aug 21, 2012 11:17 am
Location: UK

Post by tmsg »

Instructor wrote:tmsg
Your code example not contain external call 2. Do you sure you are calling
/Call("Scripts::Main", 2
?
:-) 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.

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
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

Make sure that your code not processed when type of ParseCmdLine is PCL_ONLOAD.

Offline
Posts: 60
Joined: Tue Aug 21, 2012 11:17 am
Location: UK

Post by tmsg »

Instructor wrote:Make sure that your code not processed when type of ParseCmdLine is PCL_ONLOAD.
I already do that (ie no processing of my extensions if nType==PCL_ONLOAD) because my code is inserted directly after the last

Code: Select all

if (nType == PCL_ONLOAD) return PCLE_ONLOAD;
// ... my extensionshere
.
It's all very strange...

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

tmsg
Upload Edit.c and openWildcard.js.

Offline
Posts: 60
Joined: Tue Aug 21, 2012 11:17 am
Location: UK

Post by tmsg »

Instructor wrote:tmsg
Upload Edit.c and openWildcard.js.
See sources (.7z file) in http://www30.zippyshare.com/v/6808995/file.html

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

tmsg
Visually don't see any problems. I will try to check it on next week when I get access to x64 OS.

Offline
Posts: 60
Joined: Tue Aug 21, 2012 11:17 am
Location: UK

Post by tmsg »

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.
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...
(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

Post by FeyFre »

tmsg
(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).)
Yes, it is another MS idiotic bug-feature. Real %Systemroot%\System32 directory is visible for 32bit application under %Systemroot%\sysnative, 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

Post by tmsg »

FeyFre wrote:tmsg
(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).)
Yes, it is another MS idiotic bug-feature. Real %Systemroot%\System32 directory is visible for 32bit application under %Systemroot%\sysnative, 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.
I first thought about that option as I've done exactly this for a couple of other, smaller utilities I've written myself.

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

Post by Instructor »

tmsg
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"
Maybe you have some antivirus that locked dll loading on start?

Offline
Posts: 60
Joined: Tue Aug 21, 2012 11:17 am
Location: UK

Post by tmsg »

Instructor wrote:tmsg
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"
Maybe you have some antivirus that locked dll loading on start?
That's very strange... It still doesn't work here and I have no anti-virus package whatsoever.

I will wait for the 4.9.1 release and re-check. If it still doesn't work then, I'll have a look.
Post Reply