Jump to content
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. ×

nitro322

Patron
  • Content Count

    387
  • Joined

  • Last visited

  • Donations

    $0.00 

Everything posted by nitro322

  1. By manual I just mean doing everything directly via dism and whatnot, as opposed to using something like rt7lite to automate it. Ie: mount the wim file, manually unpack, patch, and apply the service pack, manually apply other packages, etc. It's been kind of a pain in the rear to get everything setup, but I have a pretty good process worked out now that I've automated with an autoit script. I'll be happy to share the autoit script if you're interested, but it really wasn't developed with redistribution in mind, so it's rather specific in how it does things.
  2. Huh. I just did yet another complete rebuild, and now the sysprep and everything works, even with IE9 slipstreamed. Not that I'm complaining, but man, weird. Now to figure out why Windows Update is prompting me to install IE9 again even though it's already installed via slipstream...
  3. Because I'd rather slipstream it and not waste the extra time to install it after the OS is installed. That's kind of the whole point to all of this. For stuff I can't slipstream I do exactly that, but if it can be slipstreamed, then that's the goal.
  4. I have this sysprep problem as well. The process described by SmokingRope seems sound, but something about the sysprep step is rather fragile. I initially started looking into this because I had the same issue with preinstalled apps/configuration settings not being applied to the default user. I was using rt7lite originally as well, and couldn't get the sysprep step to take; it'd just fail in the same way as described above. I then tried switching to a manual build process, and that worked! ... until I tried slipstreaming IE9. Then it failed again. I've since rebuilt my image without IE9
  5. Cool, thanks. That's what I was thinking based on the screenshot, but I wanted to verify I wasn't missing anything else.
  6. InstallShield issue comes from TrID - it has an extremely high false-positive rate, and I haven't been able to find a good programmatic way to deal with it. Thanks. This is actually the better thread for this kind of request, but I saw it in the bug reports thread first so I commented there.
  7. Support is there, but it's not detecting the file properly. It's trying to unpack it as a FEAD file, same as the other commenter posted about the Firefox installer. This is another consequence of shuffling around 7-Zip. Confirmed - thanks for the report. I'm always up for checking out newer/better alternatives. Thanks for the links. I can't find a legit download source now, but the binaries themselves, best I can tell, are freely redistributable. As a result, there shouldn't be a problem keeping them included. That's 7-Zip's new generic .exe resource extraction at work. It doesn't see
  8. Noted. Can you clarify point 1? You say the file name is not located, but I don't know what file you're referring to. From the image it looks like the text is too wide for the screen, which would be more difficult to fix in Inno Setup than UniExtract itself. 2,4 - noted 3 - this is a known problem. Unfortunately, there's no easy fix (best I can tell) as it'll require completely rewriting that custom Inno Setup options page. I'm going to try to get that fixed for the next release. adblockpro.exe seems to work for me, but it suffers from the problem described here, where Install Explorer i
  9. This is two bugs in one: 1. It [em]should[/em] work in 1.6.1. To be honest, I'm not sure why it's failing. It should attempt to extract with unzip first (which it's doing), then, if it fails, attempt to extract with 7-zip (which it's not). I don't know why that's failing at the moment; the condition logic looks correct. 2. I (thought I) modified that same condition logic to try 7-zip if unzip's exit code was anything other than a 0 or 1. I even added this change to the changelog. However, I must have inadvertently undid that change at some point and didn't catch it, as the release version
  10. It works for me. I did notice a potential problem, though. As mentioned in the changelog, I now have 7-zip try extracting files last, as recent versions can incorrectly unpack some .exe files that other utilities correctly unpack. A side-effect is that Install Explorer is used to extract NSIS files by default now rather than 7-zip. InstExpl can better support NSIS 1.x files, but 7-zip, from what I've seen, better supports newer NSIS 2.x files. I'll need to shuffle some things around again to make 7-zip default for NSIS without affecting other file types. Will add to my todo file. I don'
  11. 1.6.1 is done. Download links and final changelog for the release version is available in the announcement thread. Thanks to everyone that provided feedback. gora, I'm afraid I still can't replicate this, or even offer an explanation as to why it happens. You should never see that second _temp log; it only gets written very briefly in the event of a failed extraction, then gets moved back to the main debug file. This should happen pretty much instantly, and it happens before the Extraction Failed prompt is even displayed. That it doesn't happen with 1.6 is even weirder, because I didn't
  12. Weird. I tried downloading adblockpro.exe, but I can't replicate the problem. Repeated extractions exit successfully. Regardless, though, there will be cases where this fails; as I mentioned in the changelog, detection isn't perfect due to a number of factors. As for the "file does not exist" problem, I can't think of what may cause that. The file should always be there. Even for formats that I can't log (including 7-Zip now) it should at least contain a line stating something like "Extraction of 7-Zip archives cannot be logged." Can you do me a favor? Repeat the test that failed, then
  13. Alright, I'll look into this. Merge modules (in this context) are Windows Installer components. Details: http://msdn.microsoft.com/en-us/library/aa369820%28VS.85%29.aspx
  14. If you're referring to the splash text windows (eg., "Extracting files from: NullSoft Installer installer"), I actually increased the width of these last night. I don't remember if it was before or after I released the beta, though. Give it a shot with beta2 and let me know how it looks. It seems ok to me.
  15. OK, just for the record, this has not been a quick and easy update. But, I think it'll be worthwhile at least, and I hope all of you agree. I found a few more concerns while working on the code earlier tonight, and so I decided to do my full regression testing after all. Good thing I did - I found quite a few problems, mostly in edge cases, but still... I want this to be as stable as possible. I fixed all of the problems I found and added a few more enhancements here and there as I thought of them. I'm also pleased to say that I was able to work in the "better success criteria" previously
  16. OK, gotcha. I added another 10 pixels in between, added some padding to the English to test a fifth line, and it looks good now. Thanks for the feedback.
  17. Oh, are you talking about the horizontal space to the left of the OK and Cancel buttons? If you want me to increase that for translated text, yes, I can do that. I thought you were referring to the vertical space where I removed the MSXML link. Edit: How's this?
  18. Sorry, gora, I don't quite follow you. I did remove that line on purpose, because msi2xml is the only thing that depended on MSXML and I've removed msi2xml. I also removed the extra padding I included in that GUI so that it'd match the other MethodSelect GUIs (this is the only one that had the extra download line). I'm not sure what you mean about whether it's possible to "increase a few a window". Thanks, I'll check it out.
  19. I don't disagree with you, but I prefer to stick with official versions where possible. And yes, I know "official" itself is a somewhat tenuous description of some of the utilities included in UniExtract (aspackdie included), but still... if I can't track back the package to a somewhat official source (or in this case any source), and there's no clear advantage to using the "newer" versions, then I'd rather stick with what I have and know works. Feel free to call me paranoid.
  20. OK. thanks for the info. I'll dig around a bit and see if I can find the sources myself. Would be helpful going forward as well. After some additional research: aspackdie - appears to be 1.41, which is the same version I have included in UniExtract stuffit expander - can't find any indication that this allows free redistribution; witholding for now msi.wcx - updated, good catch unlzx - appears to be 2.12, whereas I have 2.16 already included in UniExtract
  21. Well, it's not exactly incorrect, but I'd agree that it's insufficient. ... I'll give this some though to see if I can come up with a good, general, and efficient method to do better error checking, but it may need to wait until the next feature release. I have good news and bad news here. The good news is that I think I found a good way to do this. The bad news is that I can't implement it do to a long standing bug in the interaction between 7z.exe and tee.exe that I've never been able to work around. I'll give it one more crack tomorrow night to see if I can get 7z to play nicely with te
  22. OK. thanks for the info. I'll dig around a bit and see if I can find the sources myself. Would be helpful going forward as well.
  23. Thanks. Have a few questions, though: aspackdie - what version, and where did you download it? Latest version I could find is 1.41, which is already included, and official site seems dead stuffit expander - can you please provide source? As far as I'm aware, 6.x was the last freely-redistributable version. If I can update to 7.x, that'd be great, but I need to verify the license. msi.wcx - again, can you please provide the source? According to http://www.totalcmd.net/plugring/msi.html, 1.2 is the latest version, which I already have included. pea zip - version 2.x didn't behave correctly
  24. because I'm still using the old definition set from the 1.6 release, plus some new tweaks and additions. Swapping out the TrID defs file can have a major impact on file detection, and I didn't have time for this release cycle to do the thorough regression testing I normally do.
×
×
  • Create New...