BenjaminKalytta

Ok thank you, I'll also fix this one Update: I also find out various bugs concerning shell folders. In [users] Section for example none of shellfolder.x = <path> worked, it seems that no one had used it so far I you want test it in advanced I've uploaded it as http://www.kalytta.com/wihu.test.zip Now Im going to rewrite Welcome Screen things as mentioned before Benjamin

Yes I found the problem which causes this bug. Im currently fixing it. I've also an solution for the welcome screen problem. Since you set Home = <path> the path for each account also existing ones will be modified. May be I should change WIHU that way that NO default values will be applied to existing account. What do you think about that? Benjamin Benjamin

Showing user on welcome page isn't as easy as I thought before, may be I'll remove this again. I tried to find out windows default behaviour of showing the user on welcome page. 1. Disabled user accounts will never be showed on welcome page 2. User accounts that don't belong to any group (users, administrators...) will ONLY be showed if set to 1 in "UsersList" but ONLY if "local logon" is permitted in local security poilicy. 3. Only user accounts which belong to folowing groups will be showed by default: Administrators, Users, Power Users, Guests, but ONLY if "local logon" is permitted in local security policy Which is pretty difficult. If no idea how I can read out this information with Windows API calls, so Im currently not able to use this information. Benjamin

It must be default behaviour since WIHU (as expected) don't change anything in UsersList. Please verify that user "Alexander" has administrator rights. I'll verify this now. Benjamin

Hmm, showing a warning that one or more system folders have been changed isn't that difficult. But a more advanced dialog like me screenshot below is more complicated.

Yes of course you may use it. Many thanks for testing this. I see ... it means that WIHU don't change anything there. You must find "Administrator"=dword:00000001 in the list but I didn't find it. So it seems that the default behaviour is to show the Administrator by default on welcome screen. If don't want this you have to use ShowOnWelcome.x = 0. What about "Administrator.Computer" profile folder now, is there such folder now? Btw. you should use Primary = <idx> in future even if Default = <idx> is still be supported currently. Benjamin

I found and fixed the bug which causes your problem. Correct shellfolders weren't loaded before user creation. Please note, that %ThisHome% and %ThisProfile% can't be used any more in [users] section only in Software sections. In [Environment] section you may only use %ThisUser%

You set Home=%PERSONAL%, I think what you ment was Home.0=%PERSONAL% Update: But indeed there seems to be a bug which causes %ThisUser% not to be replaced correctly. Home isn't the profile folder, only the base directory! So if you want to change the profile folder use profile.x=<path> Administrator.Computer isn't created by WIHU. Wihu will create folders like: Administrator Administrator.0001 Administrator.0002 etc. Windows will use another schema: Administrator Administrator.Computer Administrator.001 Administrator.002 etc. The reason Windows creates this folder is, that Windows found out that Administrator directory already exists during profile directory creation. This could be after windows reinstallation on the same partition without formating it before. Did you use /Admin=x or /AdminPwd=x switch? Please note, that Default values like Home = x will also applied on this account then! Benjamin

Hehe, what i ment was the list before your ShowOnWelcome.1=0 What about /Admin=x or /AdminPwd=x switch? As I said, I need the registry keys before you added ShowOnWelcome key. Just use Password.x = * That's no strange profile path I'll explain step by step: 1. In [users] you set default home path (which will be used for each user if not overidden per user) Home = %PERSONAL% 2. In [Environment] you set Personal = D:\%ThisUser% 3. So this causes to create D:\Administrator for "Administrator" account, D:\Alexander for "Alexander" user account and so on. Benjamin

Of course My idea about this was something like DefaultTest = <expression> which will be used for each entries below this expression until DefaultTest is changed or an empty value (DefaultTest=) is specified. Im currently working on version 2 INI file parser. It's more time consuming as I thought before. It will be written completely in C++ code by using ATL library. As I said I'll use tabulator indentation to create sub trees in version 2 file format. Should I also allow spaces or just tabulators or both? Benjamin

Yes your solution would work. The default behaviour is to show the user account. There must be an item in your users section of your INI file where you change some Administrator account settings. This causes WIHU to override Windows default behaviour. (*) Some days ago I read a posting where one user was wondering why Administrator isn't showed on welcome screen any more after he created one additional account with administrative privileges. It seems that Windows will hide this account on welcome screen even if it isn't explicitely specified this way. But to be sure I need some information from your Windows Registry. Please could you tell me the content of the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList So if you don't want to show Administrator account on welcome screen you have to add ShowOnWelcome.x=0 If I want to restore Windows default behaviour as explained in (*) I need some one who can verify this. Then it will be a bit more complicated, but not impossible. Benjamin

I'll take this in consideration. Im currently working on it, it should take some days. Benjamin Kalytta

As you may have noticed in the past, I don't like XML. But my current INI file format isn't flexible enough, so I decided to create version 2 of ini file which works completely without indizes. Old format will still be supported. Instead of indizes I'll use tabulator indentations to create a command tree. Here you can find my example INI file which is using this new format: http://www.kalytta.com/install.2.ini If you have any additional suggestion concerning INI file just post it. Benjamin Kalytta

Hi mow, you can find a list of status flags on http://www.kalytta.com/wihu.manual.php I also added the function to show/hide user account on welcome screen in new WIHU version 2.1.20.0. Corresponding inifile keyword is ShowOnWelcome.x your status could be status.x = 0x200 (UF_NORMAL_ACCOUNT) Benjamin Kalytta

13th August, 2005: 2.1.19.13 - Some bug fixes concerning conditional command parsing like in if.true("") 13th August, 2005: 2.1.20.0 - Fixed some bugs - Added ShowOnWelcome.x keyword to show/hide user on welcome screen

It's definitely working, but it seems that you are using it the wrong way. May be you are missunderstanding the function of my tool. My tool prevents windows from logon automatically, it will NOT stop autologon for each admin account! As I said before, some applications reenable autologon in some cases such as windows network setup wizard. But just take a look at http://www.google.de/search?q=windows+regi...+AutoAdminLogon Benjamin Kalytta

Thans, Version 0.3.0 is more stable now. May be you could add some additional features like user creation interface Benjamin

Yes, this will disable autologon, and make your current account visible in welcome page. If you want specify another account than currently logged on account you may specify an alternative user account which should be used for logon in future. Then you have to use /username switch. Addition in Version 1.3: - Combo box for easy user selection - /username=%current% will select currently logged on user Benjamin Kalytta

Ok, I released version 1.2 of this tool. There are several command line switches: /silent: Don't sow UI /autologon=0 or 1 /visible=0 or 1 : show or hide user on welcome page /username=x : set user name, use "" if user name contains spaces /password=x : set password Benjamin Kalytta

Ok, I'll add a switch as soon as my computer is repaired BIOS or motherboard is broken.

Your INI file looks ok. command without .index will be used to set default keys for a specified section or to override [section] header with a more specific one. [Section name] description = Just a new Section will display "Just a new Section" instead "Section name" for example. Some things to "if" conditions: description.0 = Option (will be selected in Windows 2003 by default) command.0 = cmd.exe /c @echo Option 1.1 test.0.1 = HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentVersion?=5.2 test.eval.0 = 0 selected.0 = if.true disabled.0 = if.false Code above will evaluate the result of "test.0.1". Only if the evaluation is true, item will be selected and enabled. If the evaluation is false, item will be unselected and disabled. Benjamin Second use of if.true/false is in description text: description.0 = This is if.false("not") Windows 2003 Above will Show insert the word "not" if evaluation of "test.x.y" don't return true.

@nant15: I tried the default example INI which is shipped with WIHU by default. Some hint about loading sub commands: You could load each command recursively, i.e. make a function which accepts the level index. Just take a look at LoadSubCommands function in my source. Pseudocode of this idea: LoadSubCommand(STRING SubCommand) { for Idx = 0 TO MAX_LEVEL LoadSubCommand(SubCommand + "." + STRING(Idx)) end for } ...whereby MAX_LEVEL could be 255 at root level for example and 64 or so for sub levels. Another idea of course would be (which presumes that you are not using default PrivateProfileString functions) that you only load existing commands, i.e. don't try each level as above, but only load the command which exists: Line = LoadStringLine(LineNumber); IF (Line.Contains("command")) THEN DoSomething END IF Benjamin

It's still a bit unstable, I wasn't able to load my install.ini for example. But Im sure you'll fix this soon I think many people here using WIHU will appreciate your tool. Benjamin

Hi nant15, this tool looks great. I always want to create something like this, but I had no time so far I'll try it soon. If you want I'll add this tool to my web site. Benjamin Kalytta

I think this should work with /autoinstall=1000000000