AkelPad Forum Index AkelPad
Support forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Small problem with self-compiled x64 version

 
Post new topic   Reply to topic    AkelPad Forum Index -> Discussion (English)
View previous topic :: View next topic  
Author Message
tmsg



Joined: 21 Aug 2012
Posts: 34
Location: UK

PostPosted: Sun Sep 14, 2014 12:17 pm    Post subject: Small problem with self-compiled x64 version Reply with quote

(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
Back to top
View user's profile Send private message
Instructor
Site Admin


Joined: 06 Jul 2006
Posts: 5359

PostPosted: Sun Sep 14, 2014 6:47 pm    Post subject: Reply with quote

tmsg
Scripts-Eng.txt wrote:
Call("Scripts::Main", 2, "SCRIPT", "ARGUMENTS")
Same as previous, but wait for script completion.
?
Back to top
View user's profile Send private message Send e-mail
tmsg



Joined: 21 Aug 2012
Posts: 34
Location: UK

PostPosted: Mon Sep 15, 2014 11:41 am    Post subject: Reply with quote

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:
      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?
Back to top
View user's profile Send private message
Instructor
Site Admin


Joined: 06 Jul 2006
Posts: 5359

PostPosted: Mon Sep 15, 2014 12:22 pm    Post subject: Reply with quote

tmsg
Your code example not contain external call 2. Do you sure you are calling
Quote:
/Call(\"Scripts::Main\", 2
?
Back to top
View user's profile Send private message Send e-mail
tmsg



Joined: 21 Aug 2012
Posts: 34
Location: UK

PostPosted: Mon Sep 15, 2014 12:58 pm    Post subject: Reply with quote

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

Smile 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]
Back to top
View user's profile Send private message
Instructor
Site Admin


Joined: 06 Jul 2006
Posts: 5359

PostPosted: Mon Sep 15, 2014 1:13 pm    Post subject: Reply with quote

Make sure that your code not processed when type of ParseCmdLine is PCL_ONLOAD.
Back to top
View user's profile Send private message Send e-mail
tmsg



Joined: 21 Aug 2012
Posts: 34
Location: UK

PostPosted: Mon Sep 15, 2014 3:23 pm    Post subject: Reply with quote

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:
if (nType == PCL_ONLOAD) return PCLE_ONLOAD;
// ... my extensionshere
.
It's all very strange...
Back to top
View user's profile Send private message
Instructor
Site Admin


Joined: 06 Jul 2006
Posts: 5359

PostPosted: Mon Sep 15, 2014 3:37 pm    Post subject: Reply with quote

tmsg
Upload Edit.c and openWildcard.js.
Back to top
View user's profile Send private message Send e-mail
tmsg



Joined: 21 Aug 2012
Posts: 34
Location: UK

PostPosted: Mon Sep 15, 2014 5:05 pm    Post subject: Reply with quote

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

See sources (.7z file) in http://www30.zippyshare.com/v/6808995/file.html
Back to top
View user's profile Send private message
Instructor
Site Admin


Joined: 06 Jul 2006
Posts: 5359

PostPosted: Tue Sep 16, 2014 6:42 am    Post subject: Reply with quote

tmsg
Visually don't see any problems. I will try to check it on next week when I get access to x64 OS.
Back to top
View user's profile Send private message Send e-mail
tmsg



Joined: 21 Aug 2012
Posts: 34
Location: UK

PostPosted: Tue Sep 16, 2014 9:49 am    Post subject: Reply with quote

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).)
Back to top
View user's profile Send private message
FeyFre



Joined: 07 Aug 2007
Posts: 2040
Location: Vinnitsa, Ukraine

PostPosted: Tue Sep 16, 2014 1:29 pm    Post subject: Reply with quote

tmsg
Quote:
(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.
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
tmsg



Joined: 21 Aug 2012
Posts: 34
Location: UK

PostPosted: Tue Sep 16, 2014 2:10 pm    Post subject: Reply with quote

FeyFre wrote:
tmsg
Quote:
(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).
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    AkelPad Forum Index -> Discussion (English) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


SourceForge.net Logo Powered by phpBB © 2001, 2005 phpBB Group