Asok

Hi, This post is mainly for wazer and maxXPsoft. I just tried 7quicklaunch.exe on W8 RTM and it worked just great! This was the version errored out on W8 CP. Just wanted to set the record straight about this, since a few months ago I posted it didn't work for me on W8 CP. At any rate, this program when combined with the current version of Classic Shell, and some theme and registry tuners I wrote, eliminate most of the MS crap that crept in in W7 and the horrific crap in W8, making W8 actually usable for something other than chatting with your facebook "friends". So, thank you to everyone here tha contributed to 7quicklaunch.exe!

wazer, That would be great! I hate the half-assed taskbar pinning crap on W7/W8, so for all the computers I configure, I unpin everything from the taskbar and use your tool to restore Quick Launch. That way, ANYTHING can be added to Quick Launch, unlike pinning which essentially allows only executables to be pinned. I also hate the unmovable Show Desktop on the right of the taskbar, and Quick Launch restores the Show Desktop tool on the LEFT side of the taskbar as well. Microsoft has totally butchered the UI for W8 Consumer Preview. Don't know if they'll restore the Start Menu or not when they make a final release. If they don't, it'll be a far bigger disaster for them than Vista. It would be insane for MS to try to make people use their near-useless Metro UI on laptops and desktops. Already, there's a great 3rd Party alternative to replace the missing Start Menu on W8, namely Classic Shell (http://sourceforge.net/projects/classicshell/). I use Classic Shell on W7 and Vista as well, as it's far superior to the W7 and Vista Start menus anyway. At any rate, I look forward to when you port Quick Launch Classic 7 Tool to Windows 8. Asok.

wazer, awesome program! Does exactly what I need! But it doesn't seem to work on Windows 8 Consumer Preview. For some reason regedit pops up and the script stalls. It is possible to manually activate the Quick Launch tool bar in W8 CP, so that doesn't seem to be the problem per se. Is there any chance you'll port QuickLaunchClassic7.exe for W8? (BTW, I tested this out on W8 CP installed in a VirtualBox VM as Microsoft Virtual PC does not support W8 CP.) Thanks, AsokAsus Downloads: Version 1.05 MediaFire http://adf.ly/1XioU RapidShare http://adf.ly/1Xios Old Versions: Version 1.04 ENGLISH + SOURCE http://www.multiupload.com/VFVKMOTN7D DANISH + SOURCE http://www.multiupload.com/CWZSMKM60B Version 1.03 ENGLISH + SOURCE http://www.multiupload.com/YFKXANVJ3X DANISH + SOURCE http://www.multiupload.com/ZZ2H5N7TAV If you wanna translate feel free to it, provide me with links after and ill update the links.

CoffeeFiend, Using ClassicShell, can you boot straight into the desktop, or do you still have to do that by hand once the system is done loading? Incidentally, you've said that your alternative to Windows (8) would be the Mac. I heard this today on the Security Now! podcast, and I'm curious to hear what you have to say: (empahsis added)And, to keep this post on-topic, there's this: The entire discussion is worth listening to, or reading. There's a number of things that address the needs of developers specifically (such as the loss of program features). Do a search for "sandboxing" on that page, start there and read to the end of it about halfway down the page as indicated by the scrollbar. What do you think? If Apple continues the trend, does it make the Mac a less viable alternative? --JorgeA Methods that work to bypass or disable Metro UI in Windows 8 Developer Preview do not work in Windows 8 Consumer Preview. Also, methods based on using the Task Manager and methods that are based on a showdesktop.scf don't work either. However, I discovered that overriding the default registry value: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "Shell"=explorer.exe with [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "Shell"="explorer.exe /select,explorer.exe" does in fact automatically skip past Metro UI (under most circumstances). One can also do this override on a per-user basis with: [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon] "Shell"="explorer.exe /select,explorer.exe" In this latter case, you could dip your toe in the water by creating a new login Id to experiment on before applying the change system-wide with the first case. Note that in either case, after one logs on, it takes a couple of seconds for the desktop background to appear after the initial root folder for the user appears. Also, note that this method leaves a vestigial explorer.exe process that remains in the background until a logoff occurs. I also made two .reg files, one for the HKLM change and one for the HKCU change, which can be used to apply the desired change. These are in a zipped folder that can be downloaded from: http://www.reliancepc.com/menu/tips/Downloads/GoToClassicDesktopRegFiles.zip (Needless to say, if you decide to give this a try, be careful, do a system restore point, and be prepared to enter Safe Mode [if you can figure out how], or understand how to bring up the Task Manager with Ctrl-Alt-Del and start regedit.exe with Administrative privileges if you happen to get in real trouble.) I also recommend that you disable the hateful lock screen via gpedit.msc by going to: Local Computer Policy -> Computer Configuratoin -> Administrative Templates -> Control Panel -> Personalization -> "Do not display the lock screen" and setting that to "Enabled". Update: Classic Shell 3.5 breaks the above Metro Bypass reg hacks. I disabled the new Classic Shell start service and modified the regisgtry hacks as follows: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "Shell"="explorer.exe /select,explorer.exe,\"%ProgramFiles%\\Classic Shell\\ClassicStartMenu.exe\"" or [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] "Shell"="explorer.exe /select,explorer.exe,\"%ProgramFiles%\\Classic Shell\\ClassicStartMenu.exe\"" which will bypass Metro UI and start Classic Shell. BTW, these versions are not the ones in the downloaded .reg files, though you can copy and paste one of them into your own .reg file with a header line of Windows Registry Editor Version 5.00 and the second line being a blank line.

Hi, The modified .sfx modules are great: they're the basis for all of my tools. In fact, my most important tool is an sfx-based tool that makes other sfx-based tools by providing a customized command line interface to build the config.txt file, specify the files to be zipped and included, and to copy everything to the .exe file. (That tool, makeexe.exe can be found here Download MakeExe.exe. Unzip it and then type MakeExe.exe /? and/or use 7z to unpack it and see the internal parts and readme files. I've also attached MakeExe.exe here.) At any rate, I have a great need to know the directory from which a tool is called, because many of my tools have relative file and/or directory names as parameters, for example: myuncompress.exe dir1 dir2 ... I need something like: myuncompress.exe -SetEnvironment="MY_CD=%CD%" dir1 dir2 ... only where the -SetEnvironment="MY_CD=%CD%" is instead done either in config.txt and/or is supplied by a new intrinsic variable akin to %%T or %%S, because I don't won't my users to have to specify irrelevant information as a tool parameter. I've tried several things and none work. For instance, including SetEnvironment="MY_CD=%%CD%%" into config.txt merely yields: MY_CD=%CD% when the archive program accesses MY_CD. The situation is hopeless if a system temp directory is used for the extraction, so when I need a program that uses relative file/directory names, I have the archive extracted into a directory relative to the invoking directory with a config.txt file similar to the following: ;!@Install@!UTF-8! SetEnvironment="USE_TEMP_DIR=NO" InstallPath=".\\TempExtractDiretory" SetEnvironment="EXTRACT_DIR=%%T" GUIMode="1" ExtractTitle="Extracting myuncompress.bat" RunProgram="myuncompress.bat" Delete="%%T" ;!@InstallEnd@! Inside myuncompress.bat, I have code like Set SavedExtractDir=%CD% IF DEFINED EXTRACT_DIR ( IF /I "%USE_TEMP_DIR%" NEQ "YES" (CD ..) ) to decide if the extraction directory is relative to the calling directory, and then by doing CD .. I can obtain the directory from which the archived program was invoked. It would be so much simpler, so much more useful, and so much more elegant if a new variable like %%C was made available to indicate the invoking directory. (Note that %%S does not work because that is the location of the archive program and not the directory from which it was invoked.) (Another possibility would be to add another well-defined environmental variable %InvocationDirectory% that contains the directory path of the invoking directory, similar to %CommonDesktop%, %CommonDocuments%, etc.) Thanks, Asok. PostScript: Well, at least I now know why SetEnvironment="MY_CD=%%CD%%" does not work. The source code uses the "ExpandEnvironmentStrings" string function to expand environmental variables, but a community comment on the MS msdn.microsoft.com web page that documents this functions notes: "The 'CD' and 'ERRORLEVEL' values are not expanded Note that this function really doesn't work the same way as the CMD shell at all -- like the documementation notes, it doesn't do the fancy expansion. But it also doesn't expand the CD or ERRORLEVEL "variables" either." I really need for the source code to make a call to GetCurrentDirectory and put the results in an evironmental value, because that looks like that is the only way this information will be available to the user program. MakeExe.zip