XYplorer Beta Club

admin wrote: ↑10 May 2022 14:16 - Clone? XY64contents.exe is NOT identical to XY64ctxmenu.exe, they are totally different.

Would you say that using a non-compressed EXE would be notably faster?

highend wrote: ↑10 May 2022 12:47

Code: Select all

DetectHiddenWindows, On
ownHWND := WinExist("Ahk_PID " DllCall("GetCurrentProcessId"))

This stores it's own hwnd...

Well, assuming I know AHK

Antieve wrote: ↑05 May 2022 21:32 2. I have read the branches about the x64 version of the XY and on the whole I tend to agree that there is no special need to rewrite it.
BUT there is a huge fundamental omission in XY with starting executables, scripts etc because it starts the process directly without changing the environment for the child.
The environment variables are all WRONG for a 64-bit process (inherit from the current x32 process).
By default, a child process inherits a copy of the environment block of the parent process so we must rewrite them (tricky way) or just "proxify" to XY64ctxmenu.exe (exactly what happens when you start it with the context menu).

File --> DoubleClick --> CreateProcess = BAD
File --> RMB+Open   --> XY64ctxmenu.exe --> CreateProcess = GOOD

I don't see cases where we would want to run with a x32 environment on a x64 machine so it's strange to see that there is no "permanent redirection" (this would have closed all the cases with the advantage of the x64 version).
Of course, launching every executables and scripts via the context menu is a crutch and nobody cannot constantly keep in mind that some files cannot be launched in the usual way (or it may lead to unpredictable consequences).

Thx.

v21.10.0025 - 2020-09-29 16:06
    + Added SC open64 for debugging. Opens a file from XY64.exe, i.e. from a 
      64-bit process.
      Examples:
        open64; // Opens the selected file
        open64 "C:\Users\Donald\Desktop\Desk\Diana Rigg.jpg";

I have implemented this already

a temporary text file

1. Never use temporary files IO operations is a major time waster
2. Avoid creating processes. Start XY64ctxmenu with XY and wait for messages inside.
3. Send message from XY on RMB click. Profit.
4. Avoid any string operations in XY64ctxmenu
   The message should arrive already in the required format and be transparently proxied to the handler (when we want run x64 processes).
   As for menu, we need to minimize the use of regular expressions.
5. Avoid unnecessary checks
   Instead of checking the process\mutex\etc before each message is sent, it is better to start a timer (250-300ms) and if there is no "answer", then do a check and start the process again if it was killed for any reason.
   Deceleration in this case should not exceed the time menu opens now
   Respectively XY64ctxmenu after! opening the menu should send a "success response message"
6. One of the many ways to fix busy cursor on RMB and LMB clicks

PS
And since you will change the algorithm anyway, it makes sense to write an optimized version already for it and not kick the corpse

Antieve wrote: ↑11 May 2022 00:15

I have implemented this already