Jump to content

WinNTSetup v5.3.4


JFX

Recommended Posts

Updated v2.3.3.0 Final

- unattended file selection remembers last location (now command line also)

- better PBR detection

- language detection using default section, instead first found (Thanks wimb)

- if source has EFI boot files, both BCD store are create and used (Thanks wimb)

- Win7 Native USB 3 support check box hidden for non win7 OS installs

- new tweak to disable win8 lockscreen

Happy new year everyone!

cheers.gif

Edited by JFX
Link to comment
Share on other sites


JFX, thank you a lot for the WinNTSetup.

I have an interesting question.

Situation: while preparing the custom Windows 8 wim-image I run the system to the audit-mode by assigning a letter O: (\DosDevices\O: ) to the system-drive (i had to use any letter accept default C: ).

After syspreping all values of the registry key \DosDevices\ were erased.

Now with the normal installation, the system gets the letter C: (as usual).

But if you use the WinNTSetup with this wim-image, the program automatically writes registry key \DosDevices\O: even if an option "mount as" was not used.

Why? Where WinNTSetup reads this letter (used in audit mode) and why it decides to write the value again?

I suppose WinNTSetup does not have to write \DosDevices\ values until it's told to. Or this is like a feature?

Thanks.

vladislays, hi!

it's so nice to meet you here.

Edited by pytex
Link to comment
Share on other sites

HI pytex,

I don't remember the exact issue without setting DosDevices, but there were some problems.

WinNTSetup always clears the MountedDevices key and calculate DosDevices value for the system drive.

If the user don't specific a letter the last will be used.

It' chosen from registry: Software\Microsoft\Windows NT\CurrentVersion, Path

cheers.gif

Edited by JFX
Link to comment
Share on other sites

JFX, thanks. I see, it's a feature, WinNTSetup always adds DosDevices value for the system drive (usually \DosDevices\C: )

Now, knowing where it's choosen from, i can manipulate the value.

Link to comment
Share on other sites

  • 2 weeks later...

When I want to install XP I always launch WinNTSetup from Win7 to prepare for the installation on another drive. I noticed that when running C:\Toolbx\WinNTSetup\WinNTSetup2_x86.exe /DisableSFC, it does not set the appropriate flag in the tweaks section. I was under the impression that Disable Windows File Protection would be selected in the Tweaks section.

Edited by click-click
Link to comment
Share on other sites

First command line option must be one of the following: /NT5, NT6 or /VHD all others don't need any order.

WinNTSetup2_x86.exe /NT5 /DisableSFC should work.

Link to comment
Share on other sites

First command line option must be one of the following: /NT5, NT6 or /VHD all others don't need any order.

WinNTSetup2_x86.exe /NT5 /DisableSFC should work.

Sorry, I missed that in the spoiler. Anyway, I ran an install with DisableSFC and got errors in setuperr.log


Error:
Setup detected that the system file named [c:\windows\system32\sfc_os.dll] is not signed properly
by Microsoft. This file could not be restored to the correct Microsoft version.
Use the SFC utility to verify the integrity of the file.

***

Error:
Setup detected that the system file named [c:\windows\system32\syssetup.dll] is not signed properly
by Microsoft. This file could not be restored to the correct Microsoft version.
Use the SFC utility to verify the integrity of the file.

***

Also my dllcache still had 500MB after the install finished. I went back and redid the install without DisableSFC and setuperr.log was clean.

Edited by click-click
Link to comment
Share on other sites

These errors in setuperr.log are normal for patched files.

Version 2.3.4.0 is up. It fixed quite same bugs and should also solve your SFC problem.

cheers.gif

Edited by JFX
Link to comment
Share on other sites

Thanks for the new version. I can't say that I noticed any "bugs" lately, so now I wonder which bugs you fixed in the new release....

Also, are you saying that disableSFC was not working with XP setup before? So I should test XP setup again with the latest version?

Sorry for asking, but it's just that the previous version was working OK for me, and the only reason for a new test would be the DisableSFC thing...

Thanks for WinNTSetup!!!!

Link to comment
Share on other sites

DisableSFC patch is a bit tricky, WinNTSetup will avoid making changes to system dll files if it's not entirely sure.

Before Vista every windows language was a bit different. Cause I don't have all languages and service pack, it may not work in all version.

Most other bug were just silly coding, that properly never had cause any problem, but should have been fix.

Only serious bug was with driver integration for windows 8, while running under windows XP.

Well it's getting harder to support XP, but i don't give up yet :)

Link to comment
Share on other sites

Only serious bug was with driver integration for windows 8, while running under windows XP.

Well it's getting harder to support XP, but i don't give up yet :)

OK, thanks for your reply, but it leaves one thing open: You mention that "driver integration for W8 was buggy when running under XP".

So when you say support for XP is getting tougher, is that:

(1) Running WinNTSetup from XP (which I never use, I use WinPE_SE = W7)

(2) Using WinNTSetup to *install* XP

...or both?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...