I might start packaging it in an exe then for the next version (next month's security release most likely) in case others run in to the same issue. It shouldn't happen, an I can't recreate it here. If I run the normal script as administrator, it does ask where the updates are (because of the system32 issue), but with the test 4 script correction it does work from the original location. I don't know why I can't recreate the issue you are having here, but it's definitely related to the changing of path bug. Scripts aren't loaded into memory when run, they seem to run command by command (if you open the script, modifiy it, save it, and select another option in it, it will actually use alterations!). So, basically what is happening for you is it's like the script has been 'deleted', and therefore can't be run, because the script can't be found.
Well it seems like the .EXE format is the way to go. There must be some security measure in Win8 that prevents DOS or BAT & CMD files from executing if its not located on the OS Drive.
It's actually a longstanding bug in Windows, and if anything it is a security risk. Not for the installer of course, but potentially for other files. The security risk occurs because of the change of folder to 'C:\Windows\System32', which if you were to define the most important folder on the computer that would be it! (of course many other folders are critical too, but system32 is by far the most exceedingly critical).
Hi Burf, Yeah, it's exactly the same. With UAC totally disabled it will run without admin rights, but if you use admin rights the dos box opens and closes almost instantly. (if not run from the OS drive.)
Windows 8 has two more reg entries which do not allow scripts to run when double-clicked or right-clicked. That means the UAC disabled setting pretends to be disabled completely. To disable UAC on Windows 8 completely apply the following reg file and reboot Windows 8. Then you only need to double-click the cmd file and it should work: Code: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "ConsentPromptBehaviorAdmin"=dword:00000000 "EnableInstallerDetection"=dword:00000000 "EnableLUA"=dword:00000000 "EnableSecureUIAPaths"=dword:00000000 "EnableUIADesktopToggle"=dword:00000000 "PromptOnSecureDesktop"=dword:00000000 "ValidateAdminCodeSignatures"=dword:00000000 "dontdisplaylastusername"=dword:00000000 "FilterAdministratorToken"=dword:00000000
Funny thing is for me it works (including 'run as administrator') with just changing EnableLUA to 0. I still have some of those other settings set to their default values. It would be good to work out the root cause of the issue. Are the temp folder locations in the standard places or have they been changed to another drive etc?
On my test Windows 8 I had to apply the reg settings, too. Without, it didn't work at all. I'd be the best to package it in an exe which must be run as Administrator and extracts the cmd files in the folder where the updates are stored, just as I did it with the exe file.
Nope, the temp files are all default, my OS disk is Drive C:, so no strange setup. It's strange that this seems to be different for you Burf, but I can say that I didn't realise that UAC was not fully disabled on my system, until it came up in this thread. Now I have used the reg settings kindly provided by McRip. After the reboot, the behaviour has not changed, but at least it works, as long as I don't use Run As Administrator.
On my test setup w/ win8 x64, I have to use the reg file that I got from a friend w/c is the same as Mcrip in order to totally disable UAC.
Many thanks to komm for releasing the latest version of KUC for Windows 7. I was starting to worry that everyone had deserted Windows 7 for the delights of Windows 8...
If only there "were" delights in Win8. From my own testing it's more like every advanced function i want to perform is made 3x harder by MS and thus reducing productivity.
I will not be purchasing or loading Windows 8 in any way. I agree with McRip-a total and complete disaster. If M$ pursues this type of OS I'll be going to Linux or Mac when Windows 7 is no longer supported.