Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

15 Good

About Atari800XL

Profile Information

  • OS
    none specified
  • Country

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. 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...
  3. 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!
  4. 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?
  5. 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 :-)
  6. 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
  7. 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).
  8. Atari800XL


    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.
  9. Atari800XL


    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!
  10. 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!
  11. Sorry JFX, I see you reported the exact same errors in your November 13 post...
  12. Thank you for your reply. I'm using the version from the WinNTSetup tools folder (downloaded by WinNTSetup). It is indeed the 16299 version. I will try to find the 15063 version, can't remember now how to get it :-) (Will try). So you say 16299 has a bug, which bug is that? I find it strange that the previous previews applied fine, but not this one. Does it sound to be related to the bug you found? PS: Would the 15063 version have the same UUP file apply capabilities (will test if/when I find it).
  13. JFX, as you're the biggest imagex (and wimgapi) experts I know, I wonder if you could shed any light on this: - I downloaded the new 17063 preview UUP files yesterday, installing them with WinNTSetup worked just fine (that's unconverted UUP files, so .esd and .cab, 33 files). To repeat my imagex speed comparison test, I also tried to apply using imagex: Q:\WinNTSetup\Tools\x86\DISM\imagex.exe /apply g:\Professional_nl-nl.esd 3 c: /ref g:\*.* This worked fine with the previous preview, so I already included in some test batches. With the latest preview however, I get this error: [ 8% ] Applying progress: 10:46 mins remaining [ RETRY ] Restoring c:\Windows\InfusedApps\Frameworks\Microsoft.NET.Native.Frame work.1.6_1.6.24903.0_x86__8wekyb3d8bbwe\AppxMetadata\CodeIntegrity.cat again (Er ror = 1784) [ ERROR ] c:\Windows\InfusedApps\Frameworks\Microsoft.NET.Native.Framework.1.6_1 .6.24903.0_x86__8wekyb3d8bbwe\AppxMetadata\CodeIntegrity.cat (Error = 1784) Error restoring image. The supplied user buffer is not valid for the requested operation. Do you have any idea what's going on here, why would imagex fail where wimgapi works? I
  14. Atari800XL


    The [HELP.7] section seems to have extra double quote inside the line (col. 467, "INJECT"). Removing these seems to fix the problem (the correct way is replacing them with #$q I guess...) Just another case of PEBakery's stricter double quote rules...
  15. Atari800XL


    Alacran, I tried MistyPE with a modified Core\syswow64.script file, all the lines now have the "01" at the end of the line, instead of "\" on the end, and the "01" at the beginning of the following line. I don't really understand why these lines were concatenated in the first place, those two extra character could easily fit on the same line. But that's not the point, breaking up lines like this is used in other scripts, like 7pese wallpaper, and the script mentioned by Paraglider. We'll have to wait what Joveler thinks... With the breaks removed, the WOW64 script now works! (Not on 16299 though, we need Dave's input for that). Try an older x64 w10 release for now... You also mentioned you wanted to remove the UAC warning. This can be set in the main options, tab3 ("Options 3"), item 1 ("UAC check").
  • Create New...