BenjaminKalytta

It's already updated some says ago. Benjamin

Sorry, I'll fix this soon. I forgot to update dutch and french version. Benjamin Kalytta

No, currently only one test.eval per command is possible. your second test evaluation should be test.eval.1 = 1 which will use command.1.

I tried it. No user get created if there's no input. You'll use "Administrator" instead as daily work user.

I don't realy understand what you are doing. Do you want to delete the "Owner" User? If this is your intention, this shouldn't be possible because this isn't a real user. It is used only for internal purposes. There are various of such users, like "Everyone", "Network", "System" and so on. It's btw. also possible to delete users within WIHU. [users] user.0 = UserNameToDelete deleted.0 = 1 (It seems that I forgot to mention this somewhere in documentation) If you want an existing user to logged on automaticaly on system start, you could do following: [users] primary = 0 user.0 = Administrator password.0 = YourPassword And then start WIHU with wihu.exe /autologon

Did you get an error (batch file wasn't executed) or a warning (batch file was executed but returned an error code) ? Btw. exit code is undefined in your batch file. If you use EXIT you should return an exitcode like EXIT 0.

Concerning restart: This is currently not possible, but maybe I'll add an /NoFinishButton switch in future versions. Concerning the shell folder change warning: please add DontShowNonDefaultShellFolderWarning = 1 in your [settings] section as described in my example install.ini This was one of the features I want to add to my new Version 3.0, but currently I really don't have the time to work on WIHU that's the Problem. I get paid for another project which is important to finance my study. My idea was to create a plugin system to add more commands to be executed by wihu like: command.x = @mkdir c:\test description.x = Create new directory c:\test Version 3.0 requires a complete rewrite of WIHU which would be a very time consuming task. Im currently even not able to complete my indexless ini file concept I feel a bit sheepish about it because i announced some news about this new format in this forum some weeks ago. Benjamin Kalytta

I added /NoAbort switch to prevent a user from aborting a process. Please download the newest version of WIHU. Benjamin Kalytta

Thank you Remo, I think I found the bug. Please download the fixed version and try it again. It should work now also on T-12. Benjamin Kalytta

This button can't be disabled.

No only process specific environment block was added, i.e. not the current environment will be used. What are the error codes? Benjamin

No, there is currently no such switch. Benjamin Kalytta

Hi, this isn't really an error code. It's an exit code. Application may return exitcodes which was accessable in DOS (and also in CMD consoles) by %ERRORLEVEL%. Just ignore this.

There isn't a big difference any more. In both the user can't change selection, but if disabled is set, the item will be greyed out. May be in future versions there will be a difference like: disabled : item will never be installed, regardless if selected or not locked: item will be installed if initially selected Benjamin

Thank you. Benjamin

Ok this feature is added now. To disable this warning you have to set DontShowNonDefaultShellFolderWarning = 1 in [settings] section. Benjamin Kalytta

@midiboy. Thanks again for being so helpfull. I think I fixed all the bugs you mentioned (expected bug 4 which is on my todo list) Benjamin Kalytta

29th August, 2005: 2.1.23.1 - Many bugs were fixed especially concerning shell folder interface - Volumen selection dialog were extended - Warning dialog were added to warn about non default shell folders - Specification like ShellFolderModify.Disallow = Recent, Startup, Templates, Start Menu is also possible now - DontShowNonDefaultShellFolderWarning will enable/disable non default shell folder warning 29th August, 2005: 2.1.23.3 - Minor bugfixes. Some settings wasn't saved as "expandable string" in registry which causes Windows not to resolve the correct name after user account logon - Empty shell folders of existing user accounts will no be initialized with default values - Existing profiles: Copying of shellfolders after change now works 30th August, 2005: 2.1.24.0 - Minor bugfixes. [environment] Default shell folders wasn't applied to new user account in some circumstances - Problem concerning existing user profiles shell folder copy is fixed. 26th September, 2005: 2.1.25.0 - Minor bug concerning Environment Variables at T-12 is fixed. %USERPROFILE% wasn't detected correctly. - Added /NoAbort switch

I've completely rewritten Environment Variable Code, would be nice if you could test this new version. %USERNAME% for example may also be used in description.x now which wasn't possible so far. Benjamin Kalytta

Sorry, this is currently not possible in WIHU. Please try WIHUlite .... you may modify it for your purpose. Benjamin

25th August, 2005: 2.1.21.1 - Fixed various bugs: ShellFolder specific, user loading specific - USERPROFILE will now correctly set 26th August, 2005: 2.1.22.1 - Following environment variables are removed: 1. NewUserName (please use USERNAME instead) 2. NewComputerName (please use COMPUTERNAME instead) 3. NewUserPassword (please use USERPASSWORD instead) - Following environment variable names changed: 1. NewWorkGroupName is now WorkGroupName 2. NewOwnerName is now OwnerName 3. NewOrgName is now OrgName This 3 variables are now also defined if first setting page is skipped - Fixes in Log-Output routines

Update: I found the problem, thanks for reporting this. Problem was, that CreateEnvironmentBlock function doesn't set %USERPROFILE% variable in certain cases. Just download the newest version. Benjamin Kalytta

Im working on a helper tool for the FTP Client SmartFTP (SmartFTP Client Backup Tool) where Im also the translator of this FTP Client. Benjamin

Yes Im currently working on 2 tools at the same time, thats the problem for being so slow. But the problems on ShowOnWelcome will be resolved soon. Btw. that Administrator is showed even if another admin account is created isn't a WIHU problem. That's a strange windows behaviour, Im trying to find out why this is sometimes showed and sometimes not. Im also currently disassembling advapi32.dll (LsaEnumerateAccountRights) because I get strange (Object Not Found) errors when calling this function to get a list of account rights assigned to an user account like "Administrator" Benjamin

Hi midiboy, are you calling WIHU from GuiRunOnce? May be you can't overwrite environment variables like USERPROFILE or USERNAME. I'll test it soon Btw. just use %ThisProfile% and %ThisUser% so far ... it's also possible! Benjamin