Archive: $DESKTOP on 98


on Windows 98 SE, during the installation, it seems as if $DESKTOP is defined as "C:\WINDOWS\All Users\Desktop\", but during the uninstall, it seems as if $DESKTOP is defined as "C:\WINDOWS\Desktop\".

Can someone confirm/deny this?

what is really strange is that both of these locations are valid locations to place items that should appear on the desktop for all users.

please note that i am using "nsis20rc2.exe"

thanks,
-markus

markus dot khouri dot 1993<at>alum dot bu dot edu


You probably forgot to use SetShellVarContext all in the uninstall section too. The uninstaller doesn't remember what you've set using SetShellVarContext in the installer.


Issue with win98
Kichik,

Even I have noticed this issue.
On win98, irrespective of the shellvarcontext, $DESKTOP always points to C:\Windows\Desktop.


I experimented by putting the following code in the uninstaller.

SetShellVarContext current
MessageBox MB_OK $DESKTOP
SetShellVarContext all
MessageBox MB_OK $DESKTOP

And in both the cases it gave me "C:\Windows\Desktop" on win98 se. It works on all other OS.

Is this a bug in NSIS 2.0( version I am using ) :(


This is probably Win98 bug, because
SHGetSpecialFolderPath(NULL, b, CSIDL_COMMON_DESKTOPDIRECTORY, false);
returns NOERROR, but buffer remains empty. For CSIDL_DESKTOPDIRECTORY this works correct. As a result
... NSIS\Source\build.cpp(451): m_ShellConstants.add("DESKTOP",CSIDL_DESKTOPDIRECTORY, CSIDL_COMMON_DESKTOPDIRECTORY);
based on the SHGetSpecialFolderLocation (?) not finds this folder. But folder is correctly defined in Registry ("HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\explorer\Shell Folders" "Common Desktop"). Now it is possible to use registry value in installation script (while NSIS sources are not patched).


maybe SHGetSpecialFolderPath needs Win98 SE


I tested on Win98 SE (had not older version :) ), and placed shortcuts both to "all" and "current" folders, this worked - shortcuts appeared on the Desktop. IMHO folders mapping to Desktop works fine, problem in the system call.


It is some kind of a weird initialization problem. See this bug report for more information and a temporary solution.