AkelPad

Posted: **Sun Sep 14, 2014 12:17 pm**

(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

Posted: **Sun Sep 14, 2014 6:47 pm**

tmsg

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

?

Posted: **Mon Sep 15, 2014 11:41 am**

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?

Posted: **Mon Sep 15, 2014 12:22 pm**

tmsg
Your code example not contain external call 2. Do you sure you are calling

/Call(\"Scripts::Main\", 2

?

Posted: **Mon Sep 15, 2014 12:58 pm**

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]

Posted: **Mon Sep 15, 2014 1:13 pm**

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

Posted: **Mon Sep 15, 2014 3:23 pm**

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

Posted: **Mon Sep 15, 2014 3:37 pm**

tmsg
Upload Edit.c and openWildcard.js.

Posted: **Mon Sep 15, 2014 5:05 pm**

Instructor wrote:tmsg
Upload Edit.c and openWildcard.js.

See sources (.7z file) in http://www30.zippyshare.com/v/6808995/file.html

Posted: **Tue Sep 16, 2014 6:42 am**

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

Posted: **Tue Sep 16, 2014 9:49 am**

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

Posted: **Tue Sep 16, 2014 1:29 pm**

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.

Posted: **Tue Sep 16, 2014 2:10 pm**

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

Posted: **Mon Sep 22, 2014 9:03 am**

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?

Posted: **Wed Oct 08, 2014 3:18 pm**

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.

AkelPad

Small problem with self-compiled x64 version

Small problem with self-compiled x64 version