Jump to content

GreenMachine

Developer
  • Posts

    3,070
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    France

Everything posted by GreenMachine

  1. @Marz: 1) It sounds suspicious with the WMP 8 hotfix, but the problem is in the hotfix itself, not the method. It would need the Documents and Settings directory to add things to the default user and all userprofiles. I install WMP9, so I cannot help you there. The hot fixes are instaled one at a time, regardless of success/failure of previous hotfix. Documents ad Setting structures are already created at this point for both the "All User" and the "Default User". 2) Again, I do not do drivers, so I leave those who know to reply. Running HKCU.reg from GuiRunOnce is not very interesting: it is too late to add most Explorer and IE visual preferences, and any modifications would be only valid for the current user, probably the administrator, as opposed to all users. I also do not use $OEM$\$$ or $OEM$\$1, as I do not need to. If I did, it would only be for certain files I wanted present on the final installation, not for temporary installation files. 3) You really don't want to be using OE ... In all it seems that you are making a simple problem more complicated that you need to, thus you run into debugging problems. I have never heard of shoot the mess, or the UnPnP program, but if you are just out to disable windows services, do it from your HKLM reg file: it is much clearer, and it is far from sure that these programs you are using can function correctly from windows when the shell is not active. I am personally rather picky about how a Default user should be configured, and I manage to have it my way, only using the registry, and copying (and deleting) shortcuts. I do everything from CMDLINES.TXT, in this order: Install Windows "Extras" (WMP9, MM2, DX9, .Net, MSJavaVM, MDAC) Install non silpstreamed hotfixes Import .reg settings Delete files Add files Add/Disable Users I like to keep individual tasks isolated, and this is all I want out of an XP installation CD. Being assured that MS components interact correctly is a chore in itself. Doing the same for third party software is certainly not easier.
  2. Search the registry for the screen saver file names you are going to delete. I believe they are stored in more than one place. It would be easy to create the .reg file once you find the entries. Why not make one and share it? I would use it (albeit in a modified form ...) In terms of performance, I am more concerned with additional registry clutter than a few .scr and .jpg files. As mentioned, you should be able to copy and files to the system using the $OEM$\$* directories. I do not use this method, as (almost) the only thing I copy are shortcuts, and I delete them all just before.
  3. My opinion ... Like many here, you delete all the screensavers. I would not do this, without deleting the corresponding registry entries. I doubt it hurts, but I would either remove the screen savers cleanly, or not at all. But that's just the way I am ... You copy to the %SYSTEMDRIVE%. You should be able to use either $OEM$\$1 or $OEM$\$$ to do this automatically. (I don't use this, as I have no $$ or $1, but it should work ...) You remove all the start menu shortcuts, but don't replace them. When you delete all the logs, you will get "File in use" messages, but don't worry about it. I figure all those files are trash unless there is currently a program accessing the file. You can use your NET USER code as is. Other than that it looks fine!
  4. @RoyalBox: The code as I posted seemed to crap out after the first 2 cat hotfix. This works: FOR /f "usebackq delims==" %%i IN (`dir /b HFTYPE1\*.exe`) DO ( IF EXIST CATEXT\*.* RMDIR CATEXT /S /Q IF EXIST CATDIR\*.* RMDIR CATDIR /S /Q START "HotFix" /wait "HFTYPE1\%%~ni.exe" /q /x:CATEXT IF EXIST CATEXT\UPDATE\*.cat xcopy /d /h /y /s CATEXT\UPDATE\*.cat CATDIR\ IF EXIST CATEXT\SP2\UPDATE\*.cat xcopy /d /h /y /s CATEXT\SP2\UPDATE\*.cat CATDIR\ IF EXIST CATDIR\*_me.cat del CATDIR\*_me.cat /q IF EXIST CATDIR\dummy.cat del CATDIR\dummy.cat IF EXIST CATDIR\empty.cat del CATDIR\empty.cat FOR /f "usebackq delims==" %%j IN (`dir /b CATDIR\*.cat`) DO ( IF EXIST CATDIR\*.cat COPY HFTYPE1\%%~ni.exe SVCPACK\%%~nj.exe IF EXIST CATDIR\*.cat COPY HFTYPE1\%%~ni.exe HFDUMMY\%%~nj.exe DEL CATDIR\*.cat /Q ) )You may need to make a SVCPACK directory first. There should be a way to have a for loop that only loops once, but I got lazy. Also, I saw a few Type II fixes that had NO cat file, part of my reason for abandoning them (though I left the code in). Don't know why it is not working for you two others. Are you sure the hotfixes are the correct versions? You say that only a few installed: how do you determine this? SSVCPACK.INF looks OK ...
  5. You have my INSTALLS.CMD file on page 1 of this thread. I think it does most of what you are trying to do there, no?
  6. @Marz: You weren't going to take no for an answer, eh? Well, you posted a bit more than 20 lines of code, but I read it anyway (I think it was the double colons, space, 10 dashes, space, comment that caught my eye...) I divide the reg files, cause they were getting long and hard to read. I also copy the HKCU.reg file to %SYSTEMROOT%\System32, and make a shortcut to regedit calling it silently, so I can easily reset those settings at the click of a mouse. I would think your drivers go in <CDROM>:\$OEM$\$1\Drivers\... I don't know what's in <CDROM>:\$OEM$\$$\, but this method should not change anything in that respect. You do not need to use either of these directories for programs that are called from CMDLINES.TXT: you can store them in $OEM$, as you will do with the hotfixes. Your CD should look something like this: (according to your script) <CDROOT> -$OEM$ --MsJavaVM_3810.exe --HKLM.reg --HKCR.reg --HKCU.reg" --Filters.reg --$$ - Files to be copied to %SYSTEMROOT% (I think ...) --$1 - Files to be copied to %SYSTEMDRIVE% (Probably C:\) ---Drivers ----Nvidia4523 ---Install ----Tools -----PSKill.exe ---TOOLS ----ShootTheMessenger.exe ----UnPnP.exe --HOTFIXES ---q330994.exe ---Q815411_WXP_SP2_x86_ENU.exe ---Q819696_WXP_SP2_x86_ENU.exe ---WindowsMedia8-KB817787-x86-ENU.exe ---WindowsXP-KB820291-x86-ENU.exeYou may want to change it a little: you have a TOOLS and a Install\Tools directory. You do this: COPY "%systemdrive%\Install\Tools\pskill.exe" "%systemroot%\"You do not need to copy to HDD from $OEM$\$1\, then copy again. You can either put it in the proper $oem$ directory, or copy it directly from the CD. I don't know what your Shooter and UnPnP executables do, but if it is to stop services, as the comment suggests, why not do from a .reg file? I install .Net because I know that it will be needed at one moment or the other, and I control the installation better at this point. Even in a single user system, I do not use the built-in administrator account, so i still need to create users, which I do simply through the NET command. You can also do it from the first-time setup, and you will have any reg settings you made here. @Garth: CMDLINES.TXT goes in $OEM$, and that is what triggers it. No $OEM$, No OEM type install, WINNT.SIF or no WINNT.SIF. You can slipstream most (not all) hotfixes, and that will avoid the need of $OEM$, but your installation will not be completly up to date on critical updates, and you cannot do the "extra" programs like WMP, DirectX, etc. In CMDLINES.TXT you list calls that will be parsed by setup. Yours should look something like [COMMANDS] ".\hotfixes\recommend\recommend.cmd" ".\hotfixes\critical\critical.cmd"I prefer just one call, and DOS 8.3, but that should not matter.
  7. As you may have guessed ... I do everything from CMDLINES.TXT. My installations consist of Windows and windows add-ons/upgrades, like DX9, WMP9, MDAC, and that other stuff which I consider to be an "integrated part" of the basic Windows OS. I find CMDLINES.TXT the best place for me to do this. If you are installing 3rd party software, I can see the advantages to doing it here, and reasons that perhaps it should/must be done later. I don't install other software this way, so I cannot speak from experience. There are others out there that can guide you better. I would suggest to just taste and see. If it works, great. If not .. oh well. I would think it does depend on what exactly you are installing, etc, but your scripts are too long for me to read... some of it might belong in one place, and some in another. HKCU reg stuff should certainly be done here.
  8. I think we all got side-tracked, and nobody really expected .bat to .cmd to change anything... You originally had 3 Questions / Problems: 1) .Net did not install silently. 2) DX phoned home to get additional files. 3) You would like more "ECHO"s. The third question is simple, and you have an example in the first reply: add "ECHO Your message here" lines between the existing lines with a meaningful message. The second question: you should have the full install of DX, not the web install. I believe Aaron said it is available on the site to download, but you best hurry... That with the proper switches should cover this point. The first question: Again, it must be a question of having the right .exe file, and calling it with the right switches. I use START "Dot Net" /WAIT ".\SVCPACK\dotnetfx.exe" /Q:A /c:"install /q"You do not ... It is an installer in an installer, that is why you need two "silent" switches. The "C" switch is often used for passing command line parameters to the second executable file. As for your proposed CD layout: I would think that you can put a directory anywhere on your CD, and access it with relative paths. I put mine in $OEM$, and I do not see any disadvantage: I do not copy the files to the HDD, and I am already there when setup passes me control. Performance wise, there is no penalty. Esthetically, that's your call.
  9. @RoyalBox: I have not taken the RHSM much further lately, 'cept a couple of points. I think I will give up on the Type II hotfixes, too. I only do 4, so it is not too big of a deal. I included it in an all in one script, being the lazy sort, and giving me a chance to try CDIMAGE.EXE and CDRECORD.EXE. I implemented a renaming system as well. It works like this: Loop through executables in the HFIXES directory. Extract each one. Get the relevent .cat file. Rename the .exe based on the .cat file name. Move them to the SVCPACK directory. The two obvious flaws: No .cat file, or more than 1 .cat file. I have not seen any type 1 without a .cat file, and just one with 2 .cat files. If there are two, I use the first that I find for the name, and copy them all. What I do like is that it renames the files on criteria other than the original name. I have not built a system lately, but I am still tempted to try to add another command to the svcpack.inf file, and see what happens. Part of it looks like this: [SetupData] CatalogSubDir="\i386\svcpack" [SetupHotfixesToRun] Q815021.exe /n /q /u /z qchain.exeOf course the hotfix has to be there, and it has it's corresponding .cat file, but QCHAIN has no "required presence", nor .cat file. (I know it SHOULD be there.) Why can't we add something like dxsetup.exe </silent of course>? We would include the files in CatalogSubDir (="\i386\svcpack"). It should behave at least similar to other .inf files Any thoughts? My rename code: @echo off SETLOCAL ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION IF EXIST SVCPACK\*.* RMDIR SVCPACK /S /Q MKDIR SVCPACK FOR /f "usebackq delims==" %%i IN (`dir /b HFIXES\*.exe`) DO ( IF EXIST CATEXT\*.* RMDIR CATEXT /S /Q IF EXIST CATDIR\*.* RMDIR CATDIR /S /Q START "HotFix" /wait "HFIXES\%%~ni.exe" /q /x:CATEXT IF EXIST CATEXT\UPDATE\*.cat xcopy /d /h /y /s CATEXT\UPDATE\*.cat CATDIR\ IF EXIST CATEXT\SP2\UPDATE\*.cat xcopy /d /h /y /s CATEXT\SP2\UPDATE\*.cat CATDIR\ IF EXIST CATDIR\*_me.cat del CATDIR\*_me.cat /q IF EXIST CATDIR\dummy.cat del CATDIR\dummy.cat IF EXIST CATDIR\empty.cat del CATDIR\empty.cat FOR /f "usebackq delims==" %%j IN (`dir /b CATDIR\*.cat`) DO ( IF NOT EXIST CATDIR\*.cat GOTO END COPY HFIXES\%%~ni.exe SVCPACK\%%~nj.exe COPY CATDIR\*.cat SVCPACK\*.cat DEL CATDIR\*.cat /Q ) ) :END
  10. I don't believe everything I find on the internet, but THIS ARTICLE seemed to make sense (even to me...) I know it's a little old (NT4?), but I think it's still acurate.
  11. I'd still go with export/import. The whole thing ain't that big, try it. If you feel the need for copying the whole thing, I'm sure that there is an "overwrite on next reboot" queue, and I would bet it is availible from within a simple .inf file. There are certainly people on board that can tell you about those: I cannot, but it sounds like it may be what you want. Brave chap, using VNC. I would go nuts if I looked at what they did!
  12. pmcx9: I know what you mean: I, too, am very lazy. I'd say you are well on your way. I think I have all the visual settings restored correctly on my box, though I have not gone over it with a fine toothed comb. I have not played with the power stuff, and there may be some sort of hardware dependecies, so you tell us. If I may be so bold ... a few things I would like to see in a "small time system builder": Insurance, a la MS. You keep your install CD up to date, and send 'em one a month. For a certain fee ... Safe system restore. Create a 2/3 partition system: [1 = Diagnostics], 2 = System, 3 = Data, all loaded onto a "clean" HDD from CD (ghost or such - there are even enough freewares). You can use the CD or Diagnostics partition to restore the system, and leave the data intact, in the case of chronic user "install everything I can download". You would need to make sure the partitions are active/non-hidden, etc, as well as defining user's directories (i.e. "My Documents") are stored on the D (Data) disk. None of this is too difficult, and once in place, fairly maintenance free. My reasoning is that if you do not have a large customer base, you need to get more $$ per customer, while offering a quality service that they are satisfied with, and happy to pay for. You recover 2 years, or even two months of some one's data, and you are (rightfully so) their hero. Just a thought. Let us know how you get on with the last steps.
  13. Hmmm. I know that I mentioned copying the NTUSER.DAT file earlier (never tried it) ... but I must have been drunk: It would discredit afore mentioned theories! I would think that there is no way you can copy over it as such: it is locked by the system. There may be a way to add it to a queue that is used by hotfixes and installs to be replaced on next boot, but that would be beyond my scope (though others here probably DO know how). However, if you load the default user's hive, you will see that there is not that much to it. You should be able to easily weed out what you don't need, and just export/import as usual. I would also suggest importing any settings from a (more or less) clean machine, to avoid importing unnecessary settings and other registry clutter. All the other files should not be a problem. I like to delete all shortcuts, All User's and Default User's, and then add them arranged as I like to the All User profile. This also has the advantage that only administrators can move/delete them, yet they are always availible for all the users. It depends on your users, and how "Hitlerian" approach you must take, but it sure does reduce maintenance. Just looked at your last lines of code. First, let me congratulate you: this code is short enough that I actually read it to the end (you out did me above). I always use regedit instead of reg, but it looks like you are changing the users name. I have to look into that. For security reasons, one should (theoretically) rename the Administrator account and create a "dummy" "Adminstrator" account, disactivated with no rights. Couldn't find an easy way to do that, but why not: the registry is once again the answer. Thanks. ...Yes, the easiest way to do the HKCU stuff is here. You could always log on as the administrator, modify the default users account, delete all users profiles, log on to a new user with adminstrator rights, delete the administrator's profile, and the result would be nearly the same, but I digress... The fade effect, small iscons, etc, can easily be exported into .reg files, and imported, avoiding the copying NTUSER.DAT.
  14. Thanks, pmcx9. I was begining to think that there hadn't been a reply because no one finished reading it - I realized after that perhaps "Simple Guide" was not the best description. Fear not, I think that most of the work you put into the GuiRunOnce code and calls can be used here with little or no modification. I have edited the post above to include a list of available environment variables. Perhaps I should not be the one to say which method is "better": I have never tried any calls from GuiRunOnce... Last point: I just learned about the shift-f10 thing. Could have saved me hours... un4given1: you can change your name to 4given1. Peace. (I was that obvious in my finger pointing...?)
  15. Using CMDLINES.TXT. The CMDLINES.TXT file is parsed by Windows Setup after copying the $OEM$\$* directories and included files, and after running aditional inf files that may be listed in DOSNET.INF (SVCPACK.INF for example - the Slipstream Hotfix Inf file), at around the T-13 minutes mark. The syntax used is a subset of that used in normal .BAT and .CMD files, and for that reason it is easier to call a .CMD file from CMDLINES.TXT, where the syntax is richer and more familiar. The first line of CMDLINES.TXT should read [COMMANDS]. Additional lines could contain calls to various programs and setup files, wrapped in quotes. However, it seems to have become a de-facto standard to simply call one command script that contains all subsequent commands and program calls. The name of the called file listed in CMDLINES.TXT is user definable, but an 8.3 named file (FILENAME.EXT) listed in the same directory is the simplest and safest. For the sake of this example, I will name the .CMD file INSTALLS.CMD. My complete CMDLINES.TXT should now look like this: [COMMANDS] ".\INSTALLS.CMD"You could add multiple calls to the CMDLINES.TXT file, but is unnecessary, and complicates the debugging process. INSTALLS.CMD This is a standard command script file, using the normal command script syntax. You are not limited in script instructions nor program calls in this file itself, though certain programs/instructions may not work, due to the unfinished state of the windows setup. An example is the NET USE command, which you cannot use, as the Workstation service has not been started, and is required by the NET USE command. In terms of file manipulation, and program installation, INSTALLS.CMD will usually be sufficient for your installation needs. This file can often simply be the file that many use to install programs, called from the GuiRunOnce section of WINNT.SIF. The advantages of this method are that the system is logged onto the Default User profile, and changes made there are subsequently copied over to each new user, including the administrator, as that user is created. At the point CMDLINES.TXT is parsed, the only user profile that exists is the Default User profile. Installations from the GuiRunOnce WINNT.SIF section will not necessarily be installed for all users. The major disadvantage I have seen to this method is that is perhaps a little more complicated. I do not find this to be the case personally, but judging from comments here … Following are some pointers, and an attempt to clear up some misconceptions of this process. This is based on my installations, as well as certain MS documents that I have read (though they are not always correct …). Let me note that I NEVER use a $1, $$, C, or such directory in $OEM$, thus I cannot be certain that what I mention here is the same for those of you using these $OEM$ sub-directories as the means to copy files to your hard disk. 1) When CMDLINES.TXT is parsed, thus the call to INSTALLS.CMD made, the working directory is <CDDRIVE>:\$OEM$. 2) The only files copied from $OEM$ to the hard disk are those included in reserved subdirectories ($$, $1, C, D, etc). Files in the root of $OEM$ and subsequent, non-reserved directories (i.e. <CDDRIVE>:\$OEM$\SETUPS\) are NOT copied to the HDD. 3) You do not need to place your setup programs in $OEM$\$1\Installs. This is only interesting to do if you wish to access these programs AFTER the GUI reboot, when you are no longer able to access files on the CD, as you cannot know the drive letter (USUALLY D:, but it is hardware dependent). You can access the files on the CD from CMDLINES.TXT using relative paths (i.e. “.\SETUPS\SETUP1.EXE"), and they do NOT need to be copied to the HDD first. The reason to copy the files to the HDD is that there is not an easy mechanism to know which drive letter the CD has been assigned during the post GUI Reboot portion of setup. 4) A list of available environment variable for CMDLINES.TXT calls follows: D:\$OEM$>SET ALLUSERSPROFILE=C:\Documents and Settings\All Users CommonProgramFiles=C:\Program Files\Common Files COMPUTERNAME=NEWXP ComSpec=C:\WINDOWS\system32\cmd.exe Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS ProgramFiles=C:\Program Files PROMPT=$P$G SystemDrive=C: SystemRoot=C:\WINDOWS Upgrade=False USERPROFILE=C:\Documents and Settings\Default User windir=C:\WINDOWS __PROCESS_HISTORY=C:\WINDOWS\system32\setup.exe D:\$OEM$> 5) This is the ideal place to make changes to the HKCU settings that will not "stick" when made after this point, namely the Explorer and Internet Explorer default settings. This is because both these applications (so it appears to me...) save their settings when logging off. At the point the CMDLINES.TXT calls are made, contrary to the GuiRunOnce calls, the Explorer shell is not graphically "active", thus does not save settings that overwrite your own registry imports. For the non-believers and pros who know better, please note that 1 above can be verified by adding the following line to INSTALLS.CMD START "DOS BOX" /WAIT CMDA DOS window will open during setup, and you will see the working directory. From a DOS window points 2 and 3 can be verified. If you do not want to open a DOS window from INSTALLS.CMD as shown above … just type SHIFT-F10 at this point, and a DOS window will open. This is based on my installation method (NO $OEM$\$...), and the information I share here is based on classic reverse engineering techniques more than relying on (often incorrect or incomplete) official documentation. I do everything from the CMDLINES.TXT call, and it works for me. I do not use the GuiRunOnce for anything: I have completed all I need before this point. An example of what can be done at this point (my INSTALLS.CMD file): @ECHO OFF TITLE Post Install Setup :: ---------- Update MS Components ECHO Starting DirectX 9 Install. START "DirectX 9 Install" /WAIT ".\DIRECTX\DXSETUP.EXE" /opk ECHO Starting Internet Explorer 6 Install. START "Internet Explorer 6 Install" /WAIT ".\IE\ie6setup.exe" /C:"IE6WZD /S:""#e"" /Q:A /R:N" ECHO Media Player and Movie Maker Install. START "MP MM" /WAIT ".\SVCPACK\WMP9_MM2.exe" ECHO Installing Dot Net. START "Dot Net" /WAIT ".\SVCPACK\dotnetfx.exe" /Q:A /c:"install /q" ECHO Installing MDAC 2.8. START "MDAC" /WAIT ".\SVCPACK\MDAC_TYP.EXE" /Q:A /c:"dasetup.exe /q /n" ECHO Updating Microsoft JavaVM. START "JAVA" /WAIT ".\SVCPACK\msjavwu.exe" /Q:A /R:N ECHO Hotfixing. START "HOTFIX" /WAIT ".\SVCPACK\KB819639.exe" /Q:A /R:N :: ---------- Adjust the Registry ECHO Importing Registry Files. START "" /WAIT REGEDIT /S ".\SVCPACK\HKLM.reg" START "" /WAIT REGEDIT /S ".\SVCPACK\HKCR.reg" START "" /WAIT REGEDIT /S ".\SVCPACK\HKCU.reg" :: ---------- Remove files I do not like ECHO Removing useless shortcuts. RMDIR "%ALLUSERSPROFILE%\Start Menu" /S /Q RMDIR "%USERPROFILE%\Start Menu" /S /Q ECHO Removing useless folders. RMDIR "%systemdrive%\Program Files\ComPlus Applications" /S /Q RMDIR "%systemdrive%\Program Files\Online Services" /S /Q RMDIR "%systemdrive%\Program Files\Uninstall Information" /S /Q ECHO Removing HotFix Log Files. DEL "%SYSTEMROOT%\*.log" /Q /F DEL "%SYSTEMROOT%\*.txt" /Q /F DEL "%SYSTEMROOT%\*.tmp" /Q /F DEL "%SYSTEMROOT%\TEMP\*.*" /Q /F DEL "%USERPROFILE%\*.log" /Q /F :: ---------- Add files I do like ECHO Installing Custom Windows Files. XCOPY ".\PROFILES\All Users\*.*" "%ALLUSERSPROFILE%\" /E /C /Y /Q /H XCOPY ".\PROFILES\Default User\*.*" "%USERPROFILE%\" /E /C /Y /Q /H COPY ".\SVCPACK\HKCU.reg" "%systemroot%\System32\" :: ---------- Fix up the User Accouints ECHO Deleting Useless Accounts. NET USER aspnet /DELETE NET USER SUPPORT_388945a0 /DELETE ECHO Setting up Users. NET USER SysAdmin SysAdmin /ADD /COMMENT:"System Administrator Account" /PASSWORDREQ:YES NET USER User User /ADD /COMMENT:"Local User Account" /PASSWORDREQ:YES NET LOCALGROUP Administrators SysAdmin /ADD NET USER Administrator /ACTIVE:NO EXIT Bottom line ... whatever floats your boat. The better method is that with which you feel more comfortable, and that which best meets your requirements. I have multi-user systems, and insist that all my modifications are valid for all users. I have no need for the GuiRunOnce, you may.
  16. If you already have a $OEM$\$1\ Directory, you could just place the .lnk file in "$OEM$\$1\Documents and Settings\Default User\Application Data\Microsoft\Internet Explorer\Quick Launch" (assuming you have not changed the PROFILESDIR setting in WINNT.SIF). Aternativly, you could copy it to "%USERPROFILE%\Application Data\Microsoft\Internet Explorer\Quick Launch" during install. I put a copy of "My Computer" there, which is defaulted to open in explorer view, and this way I have access to explorer, as well as the my computer right click options. For the fade settings, I think you are doomed to do all the HKCU stuff. The current Registry Tweaks thread adresses this as well. Power scheme should not be a problem, I believe that is a HKLM setting, but do not know which one.
  17. Are you out of the registry yet? HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers\CloneCD. It adds a .dll file (ElbyVCDShell.dll) that handles both displaying the option (Close Tray), and performing the action. More than just a registry setting. You could perhaps get away with one DLL and a couple of registry settings, but if you go this far, might as well install the whole thing, no? I install it, and would even consider doing it for that option alone.
  18. @Kenneth Volatile Memory. The registry is basically a simple database, with a programmers interface to add/remove/edit data inside. This uses a certain amount of resources. Some entries in the registry are in almost constant use (explorer settings for example, as explorer is more the "file manager" window you see: it is also the desktop itself). To alleviate the load of extracting the data from the database each time - thousands of times per second - all the settings are stored in a fixed place in memory, where explorer can directly access it. When logoff time comes, it simply dumps the settings from memory back into the database, overwriting any modifications you may have made via a .reg file. A simple example of this behavior can be done as such: place a few icons on your desktop, log off and back on, move the items, even align them so that you know explorer is aware of them. Pull the power cord out of the PC (assuming it is not a laptop ... do what ever you need to do to cause a hard stop or reboot. Reset for example). When you log back on (after replacing the cord ...) you will find your icons just as they were last time you logged on, and not where you moved them to and aligned them. Explorer did not have a chance to save your settings. Another way to see this is to take a registry setting you modify and you know works (from HKCU, an explorer setting) modify it in regedit, log off and on and you see it has reset itself. Use regedit to modify the same setting in another users HKCU (by “loading” their .DAT “hive” file), and you will find the tweak “stuck”. My biggest problem with this is locating certain registry entries. You change the explorer view to details, doing a .reg dump before and after, and you see nothing comparing them: the registry has not yet been updated. If you wait till next logon to compare, there are MANY more differences, so it’s hard to find that one little bit somewhere… TweakUI gets around this by loading itself BEFORE the registry information is parsed, and it injects the tweaks that have been set through the users interface. Before explorer access its settings, TweakUI has insured that your modifications are taken into account. Now, if you understand that, excellent! Unfortunately, I made it all up … well, not completely: it is based on the way System Tables were implemented in an OS I worked on in the 80s. What I mean is I have no proof that what I say is correct, just my evaluation of what is happening, and it suits my needs just fine. I make XP do it my way, based on theories such as these. Of course, your actual mileage may differ … In response to your last lines: I would say it is a lot closer to 100% than 90% for explorer settings. I also think that every adjustable setting can be done in a reg file, barring those still using .ini files (rare in native MS windows applications, more frequent in third party software). Just gotta get it there at the right time. Enough for the theory: Does this help with any of your tweaks? Creating a new user, clearing all “stubpath” entries you find, and logging in the new user should be a simple enough test. What are the values of the two tweaks you mentioned earlier in the new user registry, and the default user registry. Another note on stubpath. Clearing this entry will cause certain programs not to perform their initialization routines for new users. That is the whole reason I do this. I do not have a need for these initializations, but you may. By not having a "stubpath" entry for IE, it no longer does it's spiel when a new user first logs on, and does not adds it's icon all over the place. Outlook Express icons are no longer put in the quick launch bar. I like it clean. Last note: as I think about it, the stubpath is probably not your problem: don't others have those tweaks working? You need to find out what is in the default users .DAT file. I dd, however, think it is a likely suspect for RyanVM. Keep us posted.
  19. Thanks, Kenneth, for the compliment. In fact I do not really know the internals of Windows - I have not had a computer class in nearly 20 years - but I do now how to pragmatically debug. I have run into the same problems as many here, and am too stubborn not to make it work. I try to share my experience as to what has worked for me, what appears to me to be happening, and how I would proceed to locate certain problems. I will not attempt to post a process description, because I do not care to have to justify myself to those that know better. There are enough people here who concider themselves pro's that can do that... That said and done, I will tell you what I think your problem might be, and steps you can take in finding the answer: I do not have the answer myself. I implement both the tweaks you are talking about, as well as the small icons that RyanVM mentions, and they "stick": all users get them as defaults. I cannot say if my way will work for you, but it works for me... Background: If you have the tweaks added to the registry from the CMDLINES.TXT file, as I assume you have (right Ryan ...), they will be added to the default users settings, normally found in C:\Documents and Settings\Default User\NTUSER.DAT. This .DAT file contaings the HOT_KEY_CURRENT_USER (HKCU) registry hive ("section"), and is used as a template for every user created, including the built-in "Administrator" account. For Explorer and IExplorer it is important that these settings be in the template, as you cannot add them with a .reg file to an existing Profile (User account). This is because windows will update Explorer and IExplorer settings on log-off with the current settings (behaviour by design). The tweaks both you and RyanVM are talking about fall into this category. Debugging questions are: are these tweaks pressent when a new user first logs on? (It looks like no, but check the registry), and are these tweaks included in the default .DAT file mentioned above. For the first question, you can see the answer directly with regedit. For the second, you will need to use regedit, load the afore mentioned hive, and see if it is there. I hypothosize that this will show you that the tweaks are in the default user file (template), but are changed somewhere after the template is copied to a new user, and the new user can access regedit to verify. If the above is indeed the case, my next question is why does it work for me, and not you. Again, I can only hypothosize, but I suspect it is due to an additional tweak I add to the registry, in a value named "Stubpath". Stubpath is a pointer to a program to execute. A stub is a standard, though perhaps less common, programming item. There are many places that can tell you better than I what exactly it means: google it if you are curious. In any event, there are about 10 of these I have found, and I believe that they are all used to initialize the environment of the specific program. Programs that use this in XP include IE, Explorer, Outlook Express, WMP, Netmeeting, and more. I cleared all these entries from the registry, as I do not want these programs initializing at regisrty settings, reverting back to WMP from winamp just because a new user has logged on. Conclusion: I think that a program is re-initalizing your reg tweaks with default values AFTER the registry is copied from the "template" via one of these stubs, and that is why it is not working for you. What you can do: Examine both the HKCU branch of the registry of a brand new user, and that of the C:\Documents and Settings\Default User\NTUSER.DAT, which you will need to load first. If they are different, clear out all the stubpath entries, and create a new user (or remove the users profile), and see if the settings "stick". As I said, I get all the settings y'all do not, and this is the main difference I see in my setup. I also think that I am the only one who bothers with the stubpath stuff, so I doubt there is someone who could confirm this right now. You can do the tests on an existing system, so please do, and let me know. Sorry for the lengthy post, but I am hoping that it can add some insight if you are truely interested, and weed out those who are not truely interested by simple long windedness. Phew .....
  20. You cannot import those tweaks: they are reset to current values at logoff. Look HERE for more.
  21. I mean HERE. Just the way I do it, not an authoritive guide. You will need to know about CMDLINES.TXT and how to use it. I've posted alot around here about how I use it.
  22. ...Back on track RyanVM that was the answer I was hoping for. Nothing wrong with the UPDATE.CMD, it has to be a combination of WINNT (OEM settings) where the files are placed <ROOT>\I386\$OEM$\ or <ROOT>\$OEM$\, or perhaps something so silly as UPDATE.CMD.txt, or saving in an incorrect format. Did you still see the "1 file copied"?
  23. That's a lot of reading: I thought you where going to make things easier! The explorer settings you are trying to import are in the HOT_KEY_CURRENT_USER (HKCU) section. It is a chicken and egg thing, where you need to make those changes before you logon, as windows overwrites them with current settings on shutdown. You need to make the changes to the Default Users account. There was a long thread on it not too long ago with examples how to make it work. I don't remember the title, but I did post there if you do a search.
  24. 5 to go. I do have a script that does all the slipstreaming, hotfixes, etc, if you are really interested. I made it to use it, and I do, but don't post it because I would not look forward to "defending" it or any "mine's bigger than yours" contests.
×
×
  • Create New...