Jump to content

RicaNeaga

Members
  • Posts

    845
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by RicaNeaga

  1. Besides requesting once more that very useful ability to Auto-Select Language, Locale and Keyboard Locale (when you'll have the time, of course), I have two suggestion regarding Unnatended Creator:

    1. A warning for users when they start the creator to choose between the x86 and x64 architectures at the top (the interface is a little akward, and this option may be unintentionally skipped), or perhaps it's better to show it under general category;

    2. A warning for users when they choose the skip auto-activation to also insert a generic serial from the info tab (this is how I understand this option works).

  2. Nope, if you install a x86 os with x86 drivers integrated in a x86 os, you're in trouble if you have a Intel chipset for the machine you're installing the os to.

    If you install a x64 os with x64 drivers integrated in a x64 os, everything it's ok.

    The problem is how DISM (probably) sees mixed x86/x64 Intel chipset drivers - as only x64 ones. :) Or it isn't integrating them as it should.

  3. 1. I understand that now they are just for show, but in version 50 they showed what drivers would be integrated wrong by DISM. It really did.

    2. The only drivers that are integrating ok from the 9.2.3.1022 version of chipset Intel drivers in a x86 environment are the USB drivers. AND in version 50 they WEREN't red marked. If this doesn't mean anything for the way DISM sees things - you know better.

    3. It's only happening in a x86 environment. I haven't had such problems in a x64 environment, but I'll check when I'll have the time.

    4. The drivers were integrated through your app, but probably were marked as only x64 by DISM. Or I don't have an explanation for why this is happening.

    5. You can find ALL the chipset drivers here - please download version 9.2.3.1022.

    Hope my feedback help and hope you'll sort this out. It's a very important bug. I'll be back later for other info.

  4. Unfortunately the bug is still present in version 52 of your app. And I repeat, 90% probably a DISM bug.

    I don' think it's system/configuration specific - the version 50 was the best version so far that recognized drivers that would not be integrated properly. Version 52 only masks this; for example I remember that the USB drivers for Intel chipsets were integrated fine, weren't red marked by your app (and also considered x86 ok by DISM).

    I dunno how I can help you further. I'm sure 100% that integrating those chipset drivers for another windows and another Intel configuration will give the same results for an x86 environment :(

  5. Seem's like it's a problem with dism, just to check are you using VirtualBox, VirtualPC, VMWare, etc.. to test if your drivers are integrated?

    Nope, live system. I'll reply on this matter on tuesday, when I'l make another disk with at least version 51 beta. Hope you'll also have some time to investigate it further until then. :)

    And sorry I haven't mentioned it before, ALOT of features work more than ok in W7T, version 51 looks to me more of a close-to-final version :) Except Unattended Creator, of course :D

  6. I can't reply to a closed thread, so I'm trying to elucidate a potential (unresolved) problem of your app.

    I can confirm that in the 51 beta build of 1.3.0 the cosmetic problem of the Intel chipset drivers beeing displayed as only x64 ones was resolved. However, this doesn't assure me that the real problem is fixed.

    The real problem was the drivers were slipstreamed (maybe it was because of DISM fault) as x64 only, so in a x86 environment they weren't recognised by the 7 OS, and weren't associated with the proper hardware (Microsoft 2006 drivers were the newest for at least 6 Intel chipset HWIDs).

    So, can you confirm that this glitch was also resolved? I'll also retest it on a live x86 Intel-based system probably on tuesday.

    Also, another 2 Marvell AHCI and one AMD IDE drivers that are mixed ones (x86&x64) are seen as only x64. You can see that here and here, and can find those drivers here.

  7. A big problem with chipset drivers from Intel - all of them are VERY wrongfully seen by w7t as only x64 ones - as you can see here.

    I thought it was only a cosmetic problem, but although I slipstremed them with version 50 (windows 7 home basic x86 sp1 was the target), after windows install I had the older Microsoft drivers for chipset devices instead of newer Intel ones. Also, installing the inf utility on the live system changed nothing, I had to update all the drivers manually directing them to the unpacked folder of the inf utility.

    So please investigate this issue of not detecting the chipset intel drivers as MIXED ones, because I think that somehow they are slipstreamed in windows as only x64 ones.

    Also, if another driver is wrongfully seen by our ap, should I expect the same thing to happen - for example a mixed driver that is seen as only x64 by w7t can't be usable in a x86 environment?

  8. One question though about Everything-1.2.1.452Int_SI.exe installer: is it possible for it not to start right after the installing process took place? If I choose to make a nlite addon out of it, it will pop out its window at T-13, and that is a little awkward, and making installing of windows xp not so unattended.

    But thank you again. :)

  9. Maybe you'll have time to implement some of these in the near future (hopefully build 48) ... some great tweaks above (those that don't duplicate already implemented tweaks)... :)

×
×
  • Create New...