Software Alcohol 120% (CD&DVD burning and virtual drives) adds Shell Extension to mount files with images directly to virtual drives.
In TC 7.56/7.56a on WinXP x32 this item disappeared from context menu.
On Win7 x32 menu is OK. In Windows Explorer it's OK too.
Steps to reproduce:
1. Install Alcohol
2. In menu "View / Options / Virtual drive" set "Number of virtual drives" to 1 or more
3. Check or assign drive letter at "Drive Letter" page
4. Check some flags (e.g. iso as mostly common) at "Shell Extension" page
5. Press OK, close Alcohol
- May need to restart
6. In TC open context menu of images or virtual drive
P.S. It's possible to download "Alcohol 52% Free Edition" here - redirect to last version .exe, ~12Mb.
Alcohol 52/120 - no 'Mount image' in context menu of images
Moderators: Hacker, petermad, Stefan2, white
-
ghisler(Author)
- Site Admin
- Posts: 50386
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Please complain to the Alcohol 120% people. TC doesn't create the context menu by itself, it requests it from the system via OLE2.
Can you check whether it happens also with my test tool?
https://plugins.ghisler.com/addons/testrightclick.zip
It does essentially the same as TC, but it's a C program, not Delphi like Total Commander. If it has the same problem, you can send the link to the Alcohol 120% people too. If it doesn't do the same, the Alcohol 120% extension has problems when launched from a Delphi program.
Can you check whether it happens also with my test tool?
https://plugins.ghisler.com/addons/testrightclick.zip
It does essentially the same as TC, but it's a C program, not Delphi like Total Commander. If it has the same problem, you can send the link to the Alcohol 120% people too. If it doesn't do the same, the Alcohol 120% extension has problems when launched from a Delphi program.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
2ghisler(Author)
With test tool I have "Mount image" in context menu.
Sorry, I forgot to write in 1st post that TC before 7.56 (tested in 7.55(a)) has no problem. So I've thought that in last versions of TC something has changed...
Add:
Oh, I reread HISTORY.TXT and found key "DllLoad", whose function was unclear for me.
And "DllLoad=1" solves that problem.
But is the default "DllLoad=0" should not work in this case?
With test tool I have "Mount image" in context menu.
Sorry, I forgot to write in 1st post that TC before 7.56 (tested in 7.55(a)) has no problem. So I've thought that in last versions of TC something has changed...
Add:
Oh, I reread HISTORY.TXT and found key "DllLoad", whose function was unclear for me.
And "DllLoad=1" solves that problem.
But is the default "DllLoad=0" should not work in this case?
-
ghisler(Author)
- Site Admin
- Posts: 50386
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
DllLoad=0 is a security feature against sloppy programs and extensions which try to load dlls without giving the full path. There is some risk to get some virus-infected dlls when not giving the full path to the dll. Apparently the alcohol dlls don't get loaded securely.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Do you mean case when they try to load dlls firstly from current directory, then from "%windir%" etc? And some viruses can register themselves and intercept those loads?ghisler(Author) wrote:DllLoad=0 is a security feature against sloppy programs and extensions which try to load dlls without giving the full path.
Thanks, I think that understand this feature now.
-
Balderstrom
- Power Member
- Posts: 2148
- Joined: 2005-10-11, 10:10 UTC
Most important DLLS are in the registry:
I'm not sure that loading dlls from the programs own launch folder is sloppy(?)
If not for that "feature" we wouldn't be able to override shell32, et al with wrapper dlls: i.e. "OldCigarettes" and BlackWingCat's Win2K wrapper files, that enable many so-called WinXP programs to run under Win2K.
Code: Select all
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs]
"advapi32"="advapi32.dll"
"comdlg32"="comdlg32.dll"
"DllDirectory"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\
00,74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,00,00
"gdi32"="gdi32.dll"
"imagehlp"="imagehlp.dll"
"kernel32"="kernel32.dll"
"lz32"="lz32.dll"
"ole32"="ole32.dll"
"oleaut32"="oleaut32.dll"
"olecli32"="olecli32.dll"
"olecnv32"="olecnv32.dll"
"olesvr32"="olesvr32.dll"
"olethk32"="olethk32.dll"
"rpcrt4"="rpcrt4.dll"
"shell32"="shell32.dll"
"url"="url.dll"
"urlmon"="urlmon.dll"
"user32"="user32.dll"
"version"="version.dll"
"wininet"="wininet.dll"
"wldap32"="wldap32.dll"If not for that "feature" we wouldn't be able to override shell32, et al with wrapper dlls: i.e. "OldCigarettes" and BlackWingCat's Win2K wrapper files, that enable many so-called WinXP programs to run under Win2K.
Hello, Balderstrom.
Sloppy DLL loading is loading a DLL from the current working folder unconditionally, because no programme(r) can be sure what the current working folder will be at the point in time when it loads a DLL, unless he sets the current working folder before loading a DLL from it, in which case he could simply use a fully qualified path specification instead.
In particular in cases where the current working folder may be located on a network share or even on an internet server, i.e. on machines which are controlled by others, by loading a DLL from the current working folder you run a serious risk of finding and loading a "planted" and malicious DLL there.
On Unix/Linux, even searching for executable files in the current folder is turnt off by default and not really recommended. If you wish to do so, you have to add the "." (dot) to your $PATH variable yourself. And you should never ever add it a the beginning of your $PATH, but only at the end.
So searching for executable files and shared libraries in the current folder - which may be anywhere at a given point in time - has been known to be risky behaviour for a long time. Only the Windows world chose to ignore the risk for a long time.
Kind regards,
Karl
This is not what the DllLoad parameter is all about. Nor is loading a DLL from your own programme folder what Microsoft started recommending not to do.I'm not sure that loading dlls from the programs own launch folder is sloppy(?)
Sloppy DLL loading is loading a DLL from the current working folder unconditionally, because no programme(r) can be sure what the current working folder will be at the point in time when it loads a DLL, unless he sets the current working folder before loading a DLL from it, in which case he could simply use a fully qualified path specification instead.
In particular in cases where the current working folder may be located on a network share or even on an internet server, i.e. on machines which are controlled by others, by loading a DLL from the current working folder you run a serious risk of finding and loading a "planted" and malicious DLL there.
On Unix/Linux, even searching for executable files in the current folder is turnt off by default and not really recommended. If you wish to do so, you have to add the "." (dot) to your $PATH variable yourself. And you should never ever add it a the beginning of your $PATH, but only at the end.
So searching for executable files and shared libraries in the current folder - which may be anywhere at a given point in time - has been known to be risky behaviour for a long time. Only the Windows world chose to ignore the risk for a long time.
Kind regards,
Karl