A few clarifications on the new version

Please check the FAQ (https://www.xyplorer.com/faq.php) before posting a question...
Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

A few clarifications on the new version

Post by Antieve »

It's been a while and I decided to try the new version of XY.
In this regard, I have a number of questions that I would like to clarify.
  1. How to get the same result now?
    Image
     
  2. Is there any way to "padding" toolbar icons without using "separator" (Doesn't look very pretty)
    Image
    I tried to use the transparent userbuttons for this, but it seems to be impossible to block their selection on hovering and reaction when you click.
    
     
  3. Is there an official way to replace the (any) standard toolbar icon with custom one?
 


PS
DISCLAIMER
I truly believe that XY is one of the best file managers today, so I must point out the few flaws that it still has!
Not a bug report, just a thought out loud (can be completely ignored) ;)

Things I was surprised to find out
1. The bug with the removal of "bad names" has not been fixed.
I highlight this is exactly a bug as standard function works in such cases without any problems.
Example:
In console from C:\ root do: md bug\bug..\\\
And here is a simplified version of the code (fasm) to delete it with just RemoveDirectoryA

Code: Select all

format PE64 console
entry start
include 'win64a.inc'

section '.text' code readable executable
start:
        sub     rsp,8
        ; To simplify the code we just delete sequentially
        invoke RemoveDirectoryA, DirPath2
        test rax, rax
        jz @wrong
        invoke RemoveDirectoryA, DirPath1
        test rax, rax
        jz @wrong
        cinvoke printf, <'%s',13, 10>, ' * Deleted!'
        jmp @f
        @wrong:
        cinvoke printf, <'%s', 13,10>, ' * Something goes wrong :('
        @@:
        cinvoke getch
        invoke  ExitProcess,0

section '.data' data readable  writeable
DirPath2 db 'C:\bug\bug..\',0
DirPath1 db 'C:\bug\',0

section '.idata' import data readable writeable
library kernel32,'KERNEL32.DLL', msvcrt,   'msvcrt.dll'
import msvcrt,   printf, 'printf', getch, '_getch'
import kernel32, ExitProcess, 'ExitProcess', RemoveDirectoryA, 'RemoveDirectoryA'
Compiled binary

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.

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

Thank you so much for your answers - you've been very helpful.

1. Now in Custom event actions > Clicking on line numbers > Left-click on line number = Sticky selection
2. Looks like there is no noninvasive solution for this (haven't found one yet)
3. There is patchimage but the bitmap patch in the resources seems more convenient to me

Image

I will of course solve the separator issue, but I would like to see a native solution

PS
2. I haven't tested it yet, but it looks like it can be solved with CFA (exe,msi,bat,cmd,etc > my x64 custom launcher)
3. Why CMD toolbar button starts x32 version of cmd.exe on x64 PC?

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

Let's start with this: "The bug with the removal of "bad names" has not been fixed." Are you referring to some fix in the past?

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

Antieve wrote: 08 May 2022 18:22 2. Looks like there is no noninvasive solution for this (haven't found one yet)

You can abuse the new text buttons if you use only blanks as text:
Attachments
2022-05-08_183008.png
2022-05-08_183008.png (20.64 KiB) Viewed 3274 times

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

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).
Interesting observation. But also interesting that nobody ever complained about the way it is. So, is this just a theoretical issue?

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 08 May 2022 18:28 Let's start with this: "The bug with the removal of "bad names" has not been fixed." Are you referring to some fix in the past?
There was a little discussion about in 2018
For now, the solution is simple - use windows native functions (or do it right if they are already in use)


You can abuse the new text buttons
I tried to use the transparent userbuttons for this, but it seems to be impossible to block their selection on hovering and reaction when you click


nobody ever complained about the way it is. So, is this just a theoretical issue?
I do not think that the average user will be able to relate incomprehensible bugs in the system with what he has no idea and this is an obvious reason for the lack of complaints :) It is obvious to any programmer that a windows command interpreter file will work completely differently depending on which bit rate console it is running at. The story about executable files is similar, but here I rather meant total redirection in WOW64 because of 32 bit process limitations.

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

Antieve wrote: 05 May 2022 21:32 1. The bug with the removal of "bad names" has not been fixed.
I don't know if this is some weird coincidence, but the bug has been fixed and just a few hours before your post, this fix stopped working due to another change. It will work again in the next beta.

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 09 May 2022 09:44the bug has been fixed. It will work again in the next beta.
Glad to hear! Thank you!

BTW
About XY64contents.exe and XY64ctxmenu.exe
What are they both really needed for (I mean the algorithm)?
(If you prefer, we can continue in PM)

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

In your terms: bitness proxification

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

I noticed that the x64 context menu opens with a significant delay.
Reasonable opening times is up to 100-150ms (average windows explorer speed on win10) but we have


00:00:07.933 - 00:00:08.633 = 700ms


Now a little experiment - just delete\rename XY64ctxmenu.exe and open menu again.
We see identical menu (of course it's x32, since x64 "proxy" is not available). What about opening time.


00:00:06.366 - 00:00:06.533 = 167ms - [time to search for a non-existent file etc] = ~ 100ms (acceptable)


As a result, we have the appearance of the menu ~7 times slower by default.
And busy cursor appears in both case (bad design no matter the time).

Video
it may seem that the explorer menu appears slowly, but this is only because I forgot to turn off the fade-in effect (otherwise it appears instantly)

Now in detail
  1. ahk scripts, by their nature (it doesn't matter if they are packed into an executable or not), have an extremely low execution (initialization to be precise) speed
  2. Moreover, we lose time unpacking the image because it is packed with mpress
    "run exactly as before, with no runtime performance penalties"
    "protects programs against reverse engineering"
    No one bought it, right? :) Obviously there is a slowdown and it took me exactly 5 seconds to get the full source code.
  3. Creating new process every time you press RMB
    Starting a new process is an incredibly complex task with very high overhead which has become even more difficult with the new operating systems


This is a superficial observation without any attempt to analyze the work in depth, and I asked not out of curiosity, having understood the principle of operation, I can optimize the time the menu appears.

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

If you can make it faster, great! :D :beer: :tup:

I have already tried to re-use the "XYplorer 64-bit Context Menu Helper" process and feed new data via WM_COPYDATA, but I failed to get a window handle from it. Probably because it has no own window.

BTW, those busy cursors aren't mine. They come from the system while the menu is being created.

highend
Posts: 13274
Joined: 06 Feb 2011 00:33

Re: A few clarifications on the new version

Post by highend »

Code: Select all

DetectHiddenWindows, On
ownHWND := WinExist("Ahk_PID " DllCall("GetCurrentProcessId"))
This stores it's own hwnd...
One of my scripts helped you out? Please donate via Paypal

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

admin wrote: 10 May 2022 12:43via WM_COPYDATA
This is probably the best option given the unknown buffer size when selecting many files, otherwise I would use shared memory.
admin wrote: 10 May 2022 12:43BTW, those busy cursors aren't mine. They come from the system while the menu is being created.
This happens because the operation is carried out in the same thread as the XY GUI and its cycle is blocked. Including for such things, they came up with multithreading ;)
admin wrote: 10 May 2022 12:43If you can make it faster, great! :D :beer: :tup:
It's a rather boring task to disassemble the algorithms of someone else's code, if you share the general implementation details, then of course I will write an alternative. Bad habits (such as using context menus instead of keyboard shortcuts) slow things down a lot if the menu hangs every time :maf:

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: A few clarifications on the new version

Post by admin »

Obviously there is a slowdown and it took me exactly 5 seconds to get the full source code.
I understood you got the source code already. You know, this code is not mine, I cannot comment it. Somebody wrote it for me (I don't know AHK myself), and he disappeared in the meantime. This is the only 3rd party code existing in XY.

Antieve
Posts: 72
Joined: 02 Apr 2016 20:52

Re: A few clarifications on the new version

Post by Antieve »

Do you mean that there is no communication at all between the XY and the XY64ctxmenu and it works exclusively by itself?
And why do you need a clone? (XY64contents.exe identical to XY64ctxmenu.exe inside)

you got the source code already
In general terms, the logic of the script is understandable, but the rebuilt debug version does not see the launch arguments, I last wrote something in ahk about 12 years ago and I don’t immediately understand what the problem is :bug:


PS
BTW maybe (or maybe not) you will be interested in this 1 (details), 2

Post Reply