Atari800XL

See, that makes me feel a little better :-) Just seeing your "reversal" script from June last year (that you linked to a few posts up) made me think it was just as easy as "reversing" them back the other way...

Thank you very much for that, great to get a "secret look" in the kitchen :-) Well, at least you know I'm doing my best, and each time I fail I respect YOUR work that much more. So you weren't surprised my system went belly-up with my crude attempts?

Applying Windows 11 build 26100 with WinNTSetup works fine (of course), the NoDefender tweak works, thank you very much for that. Nice to see that after a successful setup, Defender is off, so my postinstall (with all my programs and settings) is as fast as before (absolutely no need for an antivurs to keep checking these files). I also have my own little Apply tool, made in AHK (basically scripts with a GUI). Just to learn and experiment. This has also worked very well until now. Even with 26100, the only thing that has changed for me is that Defender was not deactivated. So now I'm trying to replicate what JFX has done to deactivate Defender in my own scripts. Looks like you do a series of "Image File Execution Option" settings, correct? When I set these for MpCmdRun.exe, MsMpEng.exe and smartscreen.exe, Defender does seem to be deactivated, but the system becomes incredibly unresponsive and slow. So once again, I feel like I'm so close, yet so far away from the solution :-) Do you have any tips to nudge me in the right direction? I must have these entries below wrong somehow, this is the only thing I added to an otherwise working .reg file. Without these, apply and setup runs fine, but when I add them back, the system is incredibly slow after Setup finishes. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\temp\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MpCmdRun.exe] "Debugger"="NUL" [HKEY_LOCAL_MACHINE\temp\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MsMpEng.exe] "Debugger"="NUL" [HKEY_LOCAL_MACHINE\temp\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\smartscreen.exe] "Debugger"="NUL"

Thank you for your quick replies! May I ask how the tweak works in WinNTSetup, I would like to replicate that in a manual apply. Thanks for the link to last June, when this was discussed, sorry to have missed that. Any other links are welcome, so I can read up on the matter. I have to admit I was sort of ignoring Windows 11 for a while, but now with the upcoming LTSC 2024 (and the leaked 26100 build) I think we have to learn to live with it (or at least work around it). [EDIT: Aahh, wait it minute, it all seems to be coming back to me now <g>, it's the "File Execution Options", right? --Testing now ---)

Good day to everybody. I have been out of the loop for a while, sorry about that. I'm not a big fan of Windows 11, but the new LTSC 2024h2 leaked build 26100 seems to be a decent build. On Windows 10, I used to run a short install_wim_tweak script on the install.wim before applying, to remove some components like Defender, Search and Cortana. However, this doesn't seem to work anymore with Windows 11. My question to you kind and knowledgeable people on this board: - Do you guys know of a method to remove Defender from install.wim, or at least some way to (temporarily) turn it off, etc.? - Do we really have to learn to live with Defender, or there other ways to tame it? - Does WinNTSetup have any capabilities to assist with this? If this was discussed in this thread before, please excuse my laziness, I will try to read up on the matter. Thank you!

Sorry, maybe I was not clear. I downloaded the latest Windows 11 (business) esd, then exported image 6 (Enterprise) from it, did some "servicing" on it (removing some components) and also, like I always do, delete winre.wim from it (I have no use for it, as I always use my own PE). Looks like Windows 11 is now the first OS to complain about winre.wim missing from install.wim after my manual apply and rebooting. Must be a setting/ registry setting somewhere? Thanks for listening, Antonino!

It's been a while since I've done some work on new Windows versions, but now that I have a few days off, I'm doing some experimenting with Windows 11 23h2. All my usual tweaks and settings still work OK, but it looks like I can't delete winre.wim anymore, without complaints from setup? EDIT: I don't think this is WinNTSetup related, I believe I got the error on a manual apply test There's just the one (new) error I'm getting, just before install is complete: "setup was not completed successfully", but after a reboot, everything finishes OK anyway. Can any of you friendly people give me some hints? Setuperr.log does mention "Winre not found", so I guess that is where the error message is coming from? (It's the only error in the log).

Hi JFX, how are you doing!? Have you heard about the new (?) Microsoft Validation OS? Overview Microsoft Validation OS is a lightweight, fast, and customizable Windows 11-based operating system that you can use on the factory floor to diagnose, mitigate and repair hardware defects during Windows device manufacturing. Validation OS boots into a Command Line environment to increase reliability on the factory floor and supports running Win32 apps, smoothing the transition from early hardware bring-up to retail OS and apps development. https://software-static.download.prss.microsoft.com/dbazure/888969d5-f34g-4e03-ac9d-1f9786c66749/22621.1.220506-1250.ni_release_amd64fre_en-us_VALIDATIONOS.iso What is your opinion on this? For example, what the heck is it anyway? :-) A bit more info can be found on a different forum: https://forums.mydigitallife.net/threads/discussion-microsoft-validation-os.85484/

Thank you for your reply, Alacran. I understand the points you made, but to me it would still be useful if Grub4UEFI could support my scenario on GPT, similar to the way I use Grub4DOS on MBR now (and have done for years). I like to have a few Windows operating systems on seperate (indepentant/ hidden) partitions. For example: one for "work", one for dev, one for testing, etc. I also liked the Grub4Dos/ GFXCustomizer boot menus (as I've mentioned before). I would also like to reverse the question: "Why would Grub4UEFI -not- support it?". When the different OS's are independent and invisible from each other, it's easier to make OS image backups (Terabyte, etc.). Thanks again for your reply, I know you're more interested in the VHD approach, but I hope that if you ever find some hints to my desired solutions, you will share it with us in this or other topics, as I'm sure you will. I hope you're having fun booting!

Alacran, If you have any idea for me to test HD multibooting (eg. several Windows 10 installs on separate partitions) on a GPT disk, please let me know. I have a spare laptop for testing. I really only tested Terabyte BootItUEFI on GPT once (didn't really like complicated setup), but from this test I learned that I only need one FAT32 EFI system partition, then as many NTFS partitions as I wanted for multibooting. If you find any menu.lst entries for that anywhere (on this or the other forums), I would be happy to test.

Alacran, thank you for starting this topic on MSFN. This might be a dumb question, but I'll ask it anyways, maybe others wonder about this as well: - Is it possible do do "hd multibooting" with Grub4UEFI? Like it is with Grub4Dos on MBR/BIOS systems? Or have you read anything about this being developed for future versions? I can't wrap my head around this at the moment, but maybe something similar to Terabyte's BootItUEFI, or as I said, the "old" Grub4Dos? I guess this would involve hiding some partitions, etc.? Thanks for your reply.

Thanks for this great update. Thanks also for your tips about the DPI settings, they worked like a charm. I will also mention this update to some buddies, if you don't mind...

Hey, that was pretty quick :-) Thanks, I will try it for the PE as well, but my question was more about the best way for the "Main OS" that we apply from PE (using WinNTSetup or other). So the four settings you mention should be enough. Thanks again, I will try them... > Maybe for version 5 (in a few years) ... Maybe a separate option for scaling in version 5 as well :-)

Hi JFX, just a quick question, if I may... What would be the best. quickest/ easiest way to get the display settings to (say) 175%? (we're talking about the apply stage, obviously). Can this even be done with simple registry stuff? Thanks...

Thanks for looking into this!!! Yes, it normally works all the time with the older ImageX version (have used it dozens of times). Must be some other weird thing, but it's so strange that 15063 NEVER has those issues. Oh well, not really WinNTSetup's fault, but as you're active in other fields relating to PE/ Deployment as well, it's always best to ask the master directly. (Abbodi1406 told me he doesn't use PE all that much, I've always wondered about that, we could use him around <g> but that's another topic again).

Just finished a test of direct apply of UUP files (build 18980 x64). WinNTSetup 4.0b6 performs this task with no problems (using WimgAPI 18362). (Actually, I always wonder why a lot of people bother to convert preview UUPs to an ISO, all this effort can be spared, just use direct apply, either with WinNTSetup of Imagex). I wanted to test the manual method as well (using imagex.exe from the command line, or actually from a gui/ script thingy), and to my surprise this still produces the errors below. So for manual use, I still use version 15063. Any idea why this would happen? Command line: imagex /apply pro.esd /ref: g:\uup ImageX (any version after 15063) produces errors like this: [ ERROR ] Restoring ....filename.... again {Error = 6) Error restoring image. The handle is invalid. Once again: WinNTSetup is not to blame, just wondering what's going on here...

Thank you very much, I didn't know about the fixed uup apply, I will test imagex 18362 on its own as well. Very nice to see all the recent additions to WinNTSetup!

Most excellent to see all you veterans here again lately! Yes, I agree using wimgapi for apply and wimlib for capture. I often use UUP direct apply (for insider previews), for this I use (from the PE command line) an older version of Imagex (15063, I believe). Later versions could never apply UUP files without errors, we discussed that before, but that part of the thread seems to be gone. ...or WinNTSetup, of course. JFX, I notice that after downloading the DISM files, for x86 it has wimgapi version 15063, but for x64 it is version 18362. What is the reason for that? Does the 18362 version not have the problems anymore?

I think Misty is just interested in testing stuff... I guess he likes Wimlib so much for his PE builder, that he also wonders what the most efficient way for adding packages would be, and if it could be done without using mounting/ unmounting. For me personally, mounting is not so bad, as long as I can remember not to open any explorer windows to check what's going on during unmounting :-)

I recently wondered the same... :-) (it's a small world) I know you don't like the "buggy as hell" 16299, JFX uses wimagapi from 15063 in his great WinNTSetup (I use imagex.exe from that version as well for UUP direct apply). See here: https://1drv.ms/u/s!AnNmc1rU9VMAhGfaGtiigOc0BUlV

I replaced the new (faulty) ntfs.sys on my january iso (XPSP3 + OnePiece XP final + OnePiece POS january) with the one from my december iso (5.1.2600.5782, from the XP final pack, I guess). No write errors anymore. Still, not the "clean" solution I would have liked, but just to confirm (tested on single, dual and quad core, again, for testing/ confirming).

Misty, to detect running on PEBakery, here's a quote from Joveler (taken from an older release): %EngineVersion% for integer version (Ex 090), %PEBakeryVersion% for string version (Ex 0.9.0 alpha) was added. In current version, it is recommend to use %EngineVersion% to detect PEBakery.

The FileBox root path fix makes the SE "Copy to USB device" script work, very nice! I also like the autoscroll in the ShellExecute output, and the line numbers in the log! A nice Christmax gift, looks like your original plan of having a "working version" by December (this is close enough to beta for me!) worked out... Thank you!

Thanks, that did the trick! Still very strange that the error didn't play up for me until now, sorry again for not remembering your errors (but it must have been in the back of my mind, that's why I came straight back to "the master" to ask! <g>) Thanks for the link to the previous versions, will save it!

Sorry JFX, I see you reported the exact same errors in your November 13 post...