Author: Ratko V Tomic
Date: 22:41:11 11/12/00
Go up one level in this thread
> I got no retaliatory action from deleting the wininit.exe > or dnetc.exe Microsoft Knowledge base note Q140570 describes role of wininit.exe, as quoted below. By removing wininit.exe you defeat uninstall functionality, i.e. the uninstall won't clean up correctly. Better is to look for file WININIT.INI and edit that file for lines which control wininit.exe in the undesired ways. -------------------------- Moving Files in Windows 95 Windows 95 does not implement MoveFileEx(), but does provide an alternate way for all Win32-based, 16-bit Windows-based, and MS-DOS-based applications to move, replace, or delete files (but not directories) that are currently in use. This capability is implemented through the [rename] section of a file named Wininit.ini. If Wininit.ini is present in the Windows directory, Wininit.exe processes it when the system boots. Once Wininit.ini has been processed, Wininit.exe renames it to Wininit.bak. The syntax of the [rename] section is: DestinationFileName=SourceFileName DestinationFileName and SourceFileName must reside on the same volume and be short (8.3) file names because Wininit.ini is processed before the protected mode disk system is loaded, and long file names are only available when the protected mode disk system is running. Destination and source files specified in Wininit.ini with long file names are ignored. The [rename] section can have multiple lines with one file per line. To delete a file, specify NUL as the DestinationFileName. Here are some entry examples: [rename] NUL=C:\TEMP.TXT C:\NEW_DIR\EXISTING.TXT=C:\EXISTING.TXT C:\NEW_DIR\NEWNAME.TXT=C:\OLDNAME.TXT C:\EXISTING.TXT=C:\TEMP\NEWFILE.TXT The first line causes Temp.txt to be deleted. The second causes Existing.txt to be moved to a new directory. The third causes Oldname.txt to be moved and renamed. The fourth causes an existing file to be overwritten by Newfile.txt. Applications should not use WritePrivateProfileString() to write entries to the [rename] section because there can be multiple lines with the same DestinationFileName, especially if DestinationFileName is "NUL." Instead, they should add entries by parsing Wininit.ini and appending the entries to the end of the [rename] section. NOTE: Always use a case-insensitive search to parse Wininit.ini because the title of the [rename] section and the file names inside it may have any combination of uppercase and lowercase letters. Applications that use Wininit.ini should check for its existence in the Windows directory. If Wininit.ini is present, then another application has written to it since the system was last restarted. Therefore, the application should open it and add entries to the [rename] section. If Wininit.ini isn't present, the application should create it and add to the [rename] section. Doing so ensures that entries from other applications won't be deleted accidentally by your application. To undo a file rename operation before the system is rebooted, you must remove the corresponding line from the [rename] section of the Wininit.ini file.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.