Alcohol 52/120 - no 'Mount image' in context menu of images

Please report only one bug per message!

Moderators: sheep, Hacker, Stefan2, white

Post Reply
Rodny
Junior Member
Junior Member
Posts: 16
Joined: 2007-01-30, 19:56 UTC
Location: Belarus

Alcohol 52/120 - no 'Mount image' in context menu of images

Post by *Rodny »

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.

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 39607
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

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?
http://ghisler.fileburst.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
http://www.ghisler.com

Rodny
Junior Member
Junior Member
Posts: 16
Joined: 2007-01-30, 19:56 UTC
Location: Belarus

Post by *Rodny »

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?

User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 39607
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

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
http://www.ghisler.com

Rodny
Junior Member
Junior Member
Posts: 16
Joined: 2007-01-30, 19:56 UTC
Location: Belarus

Post by *Rodny »

ghisler(Author) wrote:DllLoad=0 is a security feature against sloppy programs and extensions which try to load dlls without giving the full path.
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?
Thanks, I think that understand this feature now.

User avatar
Balderstrom
Power Member
Power Member
Posts: 2148
Joined: 2005-10-11, 10:10 UTC

Post by *Balderstrom »

Most important DLLS are in the registry:

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

User avatar
karlchen
Power Member
Power Member
Posts: 4564
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen »

Hello, Balderstrom.
I'm not sure that loading dlls from the programs own launch folder is sloppy(?)
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.

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

Post Reply