Jump to content

dencorso

Patron
  • Posts

    9,129
  • Joined

  • Days Won

    63
  • Donations

    25.00 USD 
  • Country

    Brazil

Everything posted by dencorso

  1. No. You need MSVS 6.0 for true compatibility. If you don't mind depending on .NET, then you can go as far as MSVS 2005. But no further. Win 9x/ME went EoS on Jul 11, 2006. MSVS 2008 already requires patching to work, when it does work. Later versions rarely do work, even after patching. And, BTW, MSVS 2013 is tricky to get working already on XP SP3 !!! So, no, it cannot. Sorry.
  2. Have you found this post elsewhere, Dave? It's similar to what you're using, but maybe it can be of help. Moreover, from what I've been reading around, IFSHLP.SYS seems to really be required.
  3. Well, since you found out IFSHLP.SYS is required and now it's loaded from config.sys, I think you should remove both the "Existing NDIS2 Driver" and the Intel Adapter initial entry, in Safe Mode, and then reinstall the Intel adapter once more, using Sfor's instructions...
  4. That reply is worthy the trophy, jaclaz! You're the one and only!
  5. Those are mainly rhetoric questions, just to keep the text flowing... some'll be answered further on by the author, others will remain unanswered, without compromising the intelligibility or usefulness of the content. Now, a real help request would be something like: "No matter what I do I keep getting BSOD's or black screens!!! Heeeeeeeelllppp!" So, I do agree with submix8c. @Nomen: Then again, I guess you've succeeded in derailing the thread and alienating the OP... are you happy now?
  6. Nothing, AFAIK. I was able to access MSFN every time I tried, yesterday. If you had any trouble connecting, it probably was something along the way.
  7. Sfor did manage to get his Eee PC to run on DOS drivers on 98SE, and reported it in this post...
  8. Is that a question or a statement of fact?
  9. I really don't see why it wouldn't. Moreover, the reviving of older or otherwise decommissioned machines is always an interesting topic.
  10. @sendscan: What about one of those horrible multicard-readers without any card inserted in any of the slots? Do you perchance have one of those in your machine?
  11. Yes. Both go into C:\windows\system32 ... But we now know it isn't necessary to downgrade MicrosoftUpdateCatalogWebControl.dll at all. So, you can totally forget about it and just replace muweb.dll, OK?
  12. Nice! However, to run as the SYSTEM user one may use PAExec, PsExec or RunAsSystem to run cmd, instead of the at trick. whoami.exe (part of the XP Support Tools, one may just fish it inside the installer, and use it without installing the full toolkit) is also useful to confirm one is really running as the SYSTEM user...
  13. @submix8c: Now we may be getting nearer to understanding why it happened! Thanks for the intersting info. @all: However, just to keep all fundamental info in just one post, the current situation is, to the best of our knowledge: I) Downgrading MUWEB.DLL to v. 256 is mandatory to get the MU site working again but, up to today, there's no need to also downgrade WUWEB.DLL to v. 256: WUWEB.DLL to v. 257 can be kept and is creating no problems that we know of. II) Moreover, there's no need whatsoever to either upgrade or downgrade either authcab.cab or muauth.cab, despite much talk about that both here and elsewhere. III) Nor anyone should either delete or rename the SoftwareDistribution sub-folder, which destroys the update history for sure, but does not really solve the MU site issue.
  14. This works.
  15. Try looking at TackTech...
  16. Most of the people serious enough about computing are keeping away from 8+, and waiting for MS to come back to its senses...
  17. There is an alternative muauth.cab available at http://download.windowsupdate.com/v6/windowsupdate/redist/standalone/muauth.cab which has a 2027-05-02 expiry date, but it doesn't seem to work. When I substituted the current muauth.cab by the one downloaded from the address above, MU redownloaded the one having a 2014-11-17 expiry date and overwrote the newer one... go figure!
  18. While they don't manage to get any Good Idea, they might as well stop the nonsense and deliver a brand-new SP2 for 7, bringing it up to date driverwise, and push its EoS far away, for good measure. Since they gave up on XP, 7 is, hands down, the only decent starting point they're left with.
  19. Or... it may also mean they've realized at long last such a mess has no fixing, gave it up, and are starting it all again from scratch, just to see whether they can get it right, this time over... (one can dream, cannot one?)...
  20. Of course! Wuweb.dll v. 7.6.7600.257 wasn't deprecated, only Muweb.dll v. 7.6.7600.257 was, suddenly, and for no apparent reason. However, one would face the issue only if one had already opted for MU instead of WU (which is the default also for POSReady 2009), hence no issue would be detected for users of a reasonably standard POSReady 2009 setup.
  21. Sure it's not related to unsupported OSes, but it's clearly related to the sudden deprecation of muweb.dll v. 7.6.7600.257, not at all to MUAUTH.CAB and AUTHCAB.CAB, despite the 2014-11 <ExpiryDate> inside one or both of them. And, then again, why in the world did muweb.dll v. 7.6.7600.257 get suddenly deprecated at all?
  22. It sure occurs with Server 2003, as can be found posted elsewhere, over the 'net. Then again, after I downgraded those two files MU started working again in the two XP machines I hadn't yet given this month's updates, so I got them up-to-date. After rebooting I've checked and the muauth.cab with the <ExpiryDate>2014-11 remains there. I think that's not the right lead to pursue, right now.
×
×
  • Create New...