dencorso

Hi, erpdude8! As you already know, the files for Win 98SE from Q329128 have recently surfaced in SESP30-alpha-1 and remain present in alpha-2. They are NDIS.VXD 4.10.0.2226; PPPMAC.VXD 4.10.0.2223 and VIP.386 4.10.0.2228, of course. But Q329128 also carries fixes for Win 98FE and ME. Yet, both in his anouncement and in the spupdate.inf included in SESP30-alpha-1, Gape refers to those files as if they were part of Q301453. And while both MSKB articles pertain to "multicast packets that have a TTL setting of 0 (zero)", Q301453 is for Win 2k/XP, while Q329128 is the correct article number for Win 9x/ME, and only Q329128 contains the above mentioned files. It is a fact that Q301453 points to Q329128 and vice-versa, but I don't see the point in referring to it in such a roundabout way. It is great that those files are now available, after everybody sought them for so long. And VIP.386 4.10.0.2228 IS better than 4.10.0.2227, for in some way the system becomes less resouce-hungry when 2228 is installed. I can't help but wonder whether Gape has the complete Q329128 or if he just found its files for Win 98SE somewhere. Gape, would you please be so kind as to enlighten us? You rock, both of you! Without your continued endeavours, our computing experience would be so much the poorer. Keep on the good work! Win 9x/ME forever!

Hi, teddy123! I don't know for a fact that Win 98SE will work with 2GB. I'm sure it does work with 1GB, because that's what I use in my own system. The four more important mskb articles regarding Win 9x/ME with more than 512MB of memory are: kb181594, kb181862, kb184447 and kb304943, and in view of kb304943 I'd expect you to have problems with more than 1.5GB. Crucial Q3743 also affirms Win 98SE cannot work with more than 1GB. So my suggestion to you is take out one of yours 1GB memory sticks and see whether the system boots or not. I know this is not a satisfactory solution, and I'm not proposing it as a solution, just as a test, to establish whether the problem is really "too much" memory or not. If it turns out to be the case, then I suggest you try using MaxPhysPage =38000 and MaxFileCache=30000 (thirty thousand, this is not a typo). Andrew Aronoff reports success with 2GB by using those settings, see this thread, especially post #5. MinFileCache=30000 or no MinFileCache at all should be fine also. Those settings will leave 1152MB of memory unused, that you can transform in a huge RAMDRIVE, by using Frank Uberto's excellent XMSDSK.EXE, which you should load from CONFIG.SYS. And do *NOT* load EMM386.EXE before windows, because, with more than 512MB, it will only be a source of problems, and it's not needed nor wanted by Win 98SE. Now, if you get your Win 98SE running, but it begins to crash randomly with "Windows Protection Error" messages, then you should consider removing ACPI and APM from your Win 98SE. For more about it see this thread. Of course, as yours is a multi-boot machine, you should leave ACPI enabled and APIC selected, in BIOS, for your other operational systems, in which ACPI works well. I wish you the best luck setting up your system!

OK. Thanks a lot for your swift reply. You rock!

Hi, the_guy! I have two questions for you: 1)Can you please explain to me what Q329128 has to do with MDAC ? AFAIK, it's the "Windows 98 and Windows Millennium Edition transmit multicast packets that have a TTL setting of 0 (zero)" hotfix, isn't that so? 2)If you still have it would you please upload it to, say, rapidshare or any equivalent site? I'm looking forward to testing PPPMAC.VXD 4.90.0.3002 in my system, but have been unable to get it so far. Thanks in advance. Keep on the great work!

Good news! I've been testing NDIS.VXD 4.10.0.2226 in my system again for 3 weeks, now, without any problems. I've been unable to reproduce the original issue I reported before, not having had any instance of "Internet Explorer will be closed" type errors in these three weeks, so I'm sure that what happened on my first test must have been due to some internet quirk outside my system that has been resolved already. I'm now convinced NDIS.VXD 4.10.0.2226 works OK.

That's quite true and, at the same time, it is not! In fact, RetroOS and soporific, it's complicated... kb921503 points to MS07-043, and this points back to kb921503, but also to kb924053, among other possible security updates to remedy the vulnerability in MS07-043. And here is the catch: the OLEAUT32.DLL (v. 2.40.4531.0) in Windows2000-KB921503-x86-ENU.EXE really does not work with Win 9x/ME. But VB6-KB924053-x86-ENU.exe contains no less than 5 versions of OLEAUT32.DLL, TWO of which identify themselves as v. 2.40.4519.0! One of them (named oant4.dll in the pack) does work well with Win 9x/ME and IS the most up-to-date version of OLEAUT32.DLL known to do so, even if it does have a version number below v. 2.40.4522.0, which was formerly the most up-to-date version of this file. Well, I warned you it is complicated! erpdude8 was the first to find out about v. 2.40.4519.0, but was rather terse about it. When I understood how confused was this matter, I tried to spell it out as best as I was able to, so if you want to read more on this conundrum, see my long post on it here. HTH BTW, thanks for the heads up on MSXML3 and MSXML4, RetroOS. You rock!

Great catch, eidenk! The people at MiTeC, of course, may have done it as a deliberate prank... It hadn't occurred to me to use it to look for its own PE Timestamp. It can be spoofed quite easily. The only reason I think that it's usually reliable is the fact that it is a very little known detail of the PE standard, automatically set by the linker. One has to know it's there to spoof it. PEDUMP, for instance, really is from 29/08/2001, and I just found out a newer version of it (05/4/2004) in the downlodable companion file to this MSDN article, by Matt Pietrek: interestingly enough, when you run the 2001 version it says 1988 on the sign-on message, while the 2004 version says 2001. Matt Pietrek has updated that program many times, but did not update the text of the sign-on message consistenly every time... This new version still cannot find the dates of the dependencies but has improved, for, at least, it abstains from translating 00000000 as Wed Dec 31 22:00:00 1969...

Well, for what they may be worth, here are my two cents: AFAIK it can only be done by hexediting, maybe with some help from an old debugger like good old DOS DEBUG or SYMDEB, lots of patience and some luck. This applies to Windows VXDs and to DOS formats like SYS (the classic dos device drive format), BIN, COM and EXE (the classic MZ format). Knowing something about the format's internals of the particular file you wish to localize also helps a lot. I'm sorry! I don't think it can be done, but by a case-by-case analysis. I've just looked inside FORMAT.COM with an hexeditor. It seems to be a somewhat unusual type of COM file because it seems to preserve the MZ header from the EXE file it was before conversion. While it IS common for COM files to have been converted from EXE files, using EXE2BIN, this one was not converted by that tool because EXE2BIN does not preserve any part of the MZ header, striping it instead.

Hi, celtish! There is another issue, which I feel may be more pressing for you. In really old boards, like, for instance, PCChips M537DMA33, you have the 32 Gbyte limit, which is due to BIOS. The best solution I know, for one to be able to add bigger HDDs (say 40GBytes), is a BIOS upgrade. If you are lucky and your board either already doesn't have this problem or you can find, by Googling around, a free BIOS upgrade, then all is well. If not, you should consider a paid BIOS upgrade. I did so in the past, and can say that people at e-Support <www.esupport.com> usually can provide you with very good upgrades for reasonable prices, that will breath new life into your board for some more years (my M537DMA33 went on to work for four more years, until its chipset gave way from sheer age), by permitting you to use also somewhat bigger HDDs, when those you are targeting disappear completely from market. Since this is not for free, you should, of course, consider whether a BIOS upgrade or a Mobo upgrade (perhaps to another used board) will be more cost efficient in you particular case. As always, with this things, YMMV. But I just thought that this is an option you may have to consider. And that the 30-40GByte range is still reasonable, in view of all that's been said, but maybe aready out of reach for your mobo's BIOS. Good luck finding your HDD's. BTW, to answer you other question: IMHO old Seagates are the best of them all (YMMV here also)...

Hi, bristols! erpdude8 is right: oleaut32.dll 2.40.4519 *is newer* than 2.40.4522! This is just a versioning conundrum caused by M$ habit of late of releasing parallel series of updates starting at different versions for different OSes. But it can be solved, in the case of PE executables like oleaut32.dll, by looking at the file compilation dates (aka PE Timestamps, which are MUCH more stable, becuse they're tucked away in the PE header, than common file dates, which reside in the directory entry an can change easily). To see the compilation dates in readable format one must use MiTeC EXE Explorer, or PEDUMP.EXE by Matt Pietrek, a somewhat more technical console app. For the latter, try <pedump filename.dll | find /i "timedatestamp"> and consider the first value listed (the others are usually zero, anyway, because it tries to get the PE Timestamps of the .dll dependencies and fails silently... yes, they are the result of a bug...). I've compiled a list, for some versions of oleaut32.dll, so here is it: Versions of oleaut32.dll known to work with Windows 9x/NT4/ME ========================================== PE Timestamp 04/23/1999 16:37:36 V. 2.40.4275.1 PE Timestamp 08/31/1999 23:15:11 V. 2.40.4277.1 PE Timestamp 05/04/2001 21:34:09 V. 2.40.4517.0 PE Timestamp 03/16/2001 23:09:34 V. 2.40.4518.0 PE Timestamp 07/31/2006 18:12:40 V. 2.40.4519.0 PE Timestamp 06/20/2003 02:43:41 V. 2.40.4522.0 Of course, if one knows from which packages or updates those files came, and their relative release dates, it should not be necessary to go for the PE Timestamps, but that is not always the case. But I don't think the existence of PE Timestamps is very widely known, and this is a good exemple to show their utility. Too bad only PE executables (sometimes referred to as Win 32 executables), among all possible types of executables present in the Windows OSes carry their compilation date inside. Then again, they are becoming more and more the standard for .exe, .dll, .ocx and .tlb, and that is good news! In a nutshell, changing oleaut32.dll from v. 2.40.4522.0 to v. 2.40.4519.0, despite all the apearances, *is an upgrade*, not a downgrade! HTH <Additional musings... It seems there always IS something more to be said > Relevant files found in VB6-KB924053-x86-ENU.exe, having internal name oleaut32.dll =========================================================== PE Timestamp 07/11/2006 07:19:34 V. 2.40.4531.0 Size: 631,053 bytes Name: oa2k.dll PE Timestamp 07/31/2006 18:12:40 V. 2.40.4519.0 Size: 626,960 bytes Name: oant4.dll PE Timestamp 07/31/2006 18:43:21 V. 2.40.4519.0 Size: 626,960 bytes Name: oant4ts.dll oa2k.dll was tested by erpdude8 and by MDGx, and both found it's unsuitable for use with Win 9x/ME. So I didn't test it myself but I mention it here because its version number indicates it's presently the most up-to-date version of oleaut32 in the series 4522 .... 4531, that M$ intended for Win 2k. Of these only 4522 does work with Win 9x/NT4/ME. Now, oant4.dll and oant4ts.dll, despite having the same version number and the same size, are a long way from being the same file, because they exhibit 27,906 differences in a direct binary compare. They are both intended by M$ for NT4 systems, but oant4ts is for NT4 *Terminal Server*, which, in IMHO, is much more different from Win 9x/ME than plain-vanilla NT4, so I decided the right file to pick would be oant4.dll, which I've been using, renamed to oleaut32.dll, in my system, for some time now, without any problems. I do believe erpdude8 reasoned along these same lines to select which of the 4519 files that he tested and found it works OK. I've checked the oleaut32.dll that is inside the Unofficial 98fe SP v2.2.0, he has just released. It is the same oant4.dll that I'm currently using, from its PE Timestamp. Now, the 4519 files are the latest in the series 4275....4518, which M$ had stopped updating for some time, but since they were released in the same update pack as 4531 I took it to mean, to me at least, that they are equivalent from the hotfix point-of-view, both being the most up-to-date at the moment, the main difference being that 4519 lacks the Win 2k specific features present in 4531, most possibly *the features* that render 4531 unusable with Win 9x/ME. Of course, this last comment is just my opinion, so YMMV.

Many thanks for the mods.I'll add USER.EXE 4.90.3001 to 98SE2ME soon. Keep up the good work. You're welcome! Thank you for your site, 98SE2ME and all your efforts that help us keep Win 9x alive and kicking! BTW, I sent you a PM on Jul 27th... Did it reach you?

Thanks a lot, Eck! Your feedback is most appreciated!

Well, celtish, nowadays you'll only find them used, in the rare occasions they are to be found. I service some old computers for which they are handy, so I still buy them when they appear, usually through second-hand goods sites. But this is a trial and error game, as you have to buy them blindly in an "as-is" basis, and then test them for integrity and usability by yourself, with Spin-Rite or any other suitable test program. It is best to rig up some old hardware to use it as a test machine in a pemanent basis, and be ready to accept the fact that about 1/3 of the HDD's you'll ever buy will be unusable or stop working right away during the test. The remaining usually do work well for years, although this is one endeavour where YMMV for sure...

The problem is the software, not the phones. Third party applications like Oxygen Manager substitute completely the vendor's bundled software. But even Oxygen Manager doesn't support Win 98 SE. However its much less known competitor, MobTime does, although it is very resource hungry. Both are shareware, not free. I've posted on it before, because MobTime solved my problem of managing my Nokia 6111 in Win 98SE quite nicely. It certaily supports other brands, but I don't remember which now. See: http://www.msfn.org/board/index.php?showto...70743&st=13. I use IrDA for phone to computer connectivity, and that's why I selected the 6111. Then again, if your new phone has a USB connection, maybe NUSB will suffice to solve your problem, provided it is able to map your new phone as a common storage device, same as it does to i-Pods and many cameras. You can't be sure before you try it. So, I think the best strategy would be to decide on some phones as possibilities, find friends who already have them and are willing to let you use theirs to test with NUSB, and then find out in practice which ones work, before deciding which one to buy. Good luck! HTH

I use an old MSI MS-8817 V1 StarForce MX Series (nVidia GeForce2 MX400), in my ASUS A7V600-X board (which has VIA KT-600 / VT-8237 chipsets). So I don't really need to upgrade my video drivers, but I tested the 82.69 drivers to determine their compatibility with my old nVidia. I found out that they do work. But as with any nVidia drivers newer than 29.42, if I try to "Restart in MS-DOS mode" I get a blank black screen (the system gets into MS-DOS mode, for I can type blindly commands to reboot or turn-off the ATX power source and they work, but I see no video output). The same happens with the 29.90 drivers and with every 4x.xx or 3x.xx drivers that I've tested, up to now. But I've seen no comment on this issue here, and by surfing the internet found only two references to it: [W98SE restart to MS Dos hangs] in the "Experts-Exchange", the two next-but-last comments (10.15.2002), both by josphII and [cannot Restart in MS-DOS mode], in the "WindowsBBS", post #2 (20th April 2003) by merlin. I don't reproduce the texts in those posts here because they add nothing new to what I said above, except that they show this has happened to others before. Also, if I boot the system directly in MS-DOS, without loading Windows, there is no problem with the video output, but this is to be expected, I think. Now, my question is: is this due to my specific hardware? Can some or all of you who tested 82.69, in Win 98 SE, restart in MS-DOS mode without any problems? Please do provide feedback! As a solution for those who have this issue with the GeForce2 MX400, I recommend using the 29.42 drivers, but with nvdd32.dll and nvopengl.dll from version 32.20, for added compatibility with DirectX and OpenGL. At least for me, this set up works flawlessy. And this may work with other old boards as well...

256 colors windows icon on the Start button! The icon shown on the Start button is 16x16, 16 colors in all versions of Win 9x/ME. That's because it's taken from icon group 105, within user.exe, where there are no 256 colors icons. I thought that maybe just adding a 16x16, 256 colors icon to group 105 would be enough for the 256 colors icon be used instead of the 16 colors one... It was a long shot, but I found I was right!!! So I decided to also include a 32X32, 256 colors icon, as well as substitute both original 16x16 and 32x32 16 colors icons with retouched icons using a lighter blue for better display. Now, here I offer you my results, three files: USER.EXE 4.10.0.2233 with new group 105 16x16 and 32x32 icons in both 16 and 256 colors, with the new versions of the tradicional Windows icon; a proof-of-concept version of USER.EXE 4.10.0.2233 with the same icons except for the 16x16, 256 colors, which, in this case, I substituted for Dr. Hoiby's 16x16, 256 colors icon, just to show that this is the icon used in the Start button; and a new version of my USER.EXE 4.90.0.3001, for use with 98SE2ME, with the new icons and hexedited to show the windows version correctly as 4.10.2222 A in SYSDM.CPL. I've tested each of them for more than a month on my system, without any troubles, so I feel they are safe for release. *** Warning: Of course, these modded versions of USER.EXE can only be used with the matching version of USER32.DLL!*** Download-Link: <http://rapidshare.com/files/52583808/USER256.7z.html> Thanks to eidenk for starting the topic on how to do it. See: <http://www.msfn.org/board/index.php?showtopic=93116>

I disagree. NFR is needed to run some apps. I see no real improvement to the system, besides the ability to run such apps. It sure clutters the disk. And NFR 1.1 does add a bug. <new info> And NFR 2.0 does it too! See my <updated> post on it: http://www.msfn.org/board/index.php?showtopic=103131

wow, dencorso, you have VIP.386 version 4.10.2228? GREAT! I believe that is found in the KB329128 hotfix for Win98. I think it is now available if Win98se users can ask for it now since it wasn't available a few years ago. See my latest post on how to request hotfixes from Microsoft here: http://www.msfn.org/board/index.php?showto...31579&st=80 Well, erpdude8, the merit is Gape's in getting it. I found it inside... ... and was just giving some feedback. If you downloaded it, you too already have it. But you're right: I pointed out early up (and perhaps am guilty of understatement) that Gape's reference... ... must be a mistake, because Q301453 doesn't refer to such files. So I got curious, downloaded the pack, grabbed the files from inside it and checked their versions. I was amazed to find out that all 3 files are those known to comprise Q329128, and proceeded to test them at once, except PPPMAC.VXD, because I use WinME files for my Winsock / Internet interface, as described by MDGx. The bottom line is VIP.386 4.10.0.2228 makes my surfing experience smoother, with less resource drain than v. 2227, whereas NDIS.VXD 4.10.0.2226 seems to facilitate the occurrence of "Internet Explorer will be closed" type errors, so I downgraded to v. 2225 back again. Yet, when I have more time I'll give it a more thorough testing. For the moment, however, I'll keep just vip.386 v. 2228 in my system. Note added Sept 28 2007 => I tested further and found NDIS.VXD 4.10.0.2226 did not cause the errors I described above. I reported that I'm now convinced it works OK here.

Thank you very much. I will try to reproduce it. I also should check that if there are other CDVSD.VXD versions such as 2225, 2224 etc. I have CDVSD.VXD 4.10.2224 from KB265314. Get it here :Download site Hope this helps weird, I don't have the problem Xeno86 is having on my next door neighbor's Win98 SE computer with cdvsd.vxd 4.10.2226 [this version is from Q274370 and the Q274370 patches are bundled inside the Intel Application Accelerator software). Xeno86 may have bad or outdated firmware for his CD drives. Q265405 has cdvsd.vxd 4.10.2225 {KB article no longer available from MS support} Well actually I was wondering what program has installed that buggy cdvsd.vxd 4.10.2226 on my laptop with Intel i830 chipset I don't think that my DVD drives are faulty or have outdated firmware. They are different brands, and the problem also exists on a drive I bought this year. So as I stated before - the problem occurs on 3 different computers with different chipsets and and different drives. With 4.10.2224 it works ok so far. I also think that it is significant (quote from Q274370): I had the same issue as described by Xeno86, and have solved it also by downgrading CDVSD.VXD to 4.10.0.2224. Thanks a whole lot, ElectricString, you rock! BTW, my DVD drive is an LG HL-DT-ST DVDRAM GSA-4163B, and I don't use KernelEx at the moment, so it has nothing to do with this issue. The KB265405 can still be retrieved thanks to the Internet Archive. Find it here: http://web.archive.org/web/20010717122838/...s/q265/4/05.asp As for the hotfix itself, it seems not to be available anywhere... but I'm willing to test it also, if any of you find it and post it here. Changing subjects, I've updated my VIP.386 from 4.10.0.2227 to 4.10.0.2228, and it got less resource hungry, when surfing the internet. Thanks, Gape!

Hi, Gape! You mean Q329128, for sure! That one was really hard to get. Congratulations! So, now, the only one no one has ever seen is Q265528 (the famous Vnetbios.vxd 4.10.0.2223)... Keep on the great work! Win 98 SE rules!

Scenario: In a machine set-up with Win 98SE and IE6, either fully updated or just plain vanilla, having more than one fixed drive (more than one partition is enough), select "Start -> Find -> Files or Folders" and "Local hard drives" or "My Computer", and give "*.vxd" as search mask: the search will proceed from C: to the last fixed drive letter, as expected. Do the same, but using one of the following masks: "*.c*", "*.d*", "*.dll", "*.e*", "*.exe", "*.f*", "*.i*", "*.j*", "*.m*", "*.o*", "*.r*", "*.reg", "*.s*", "*.t*", "*.tlb", "*.v*", "*.w*", "*.x*" or "*.xml": now the result can be a search through all the fixed drives or <the BUG!> if MS .NET Framework Redistributable 1.1 is installed, the search will proceed to the end of drive C: and then stop. Workaround: search each drive letter individually, and all goes well. Solution: I've not found any, up to now. By removing .NET 1.1, the bug goes away. On reinstalling it, it reapears, so there can be no doubt it is due to .NET 1.1... It is so strange, on the other hand, that it seems to be "by design", but I don't see the point of it. Have any of you found this condition before? Do you know any solutions that preserve the .NET installation? Is it due to any configurable policy or the like? Your advice is most welcome. Adding .NET 2.0 to a system that already has .NET 1.1 does not affect the bug. Removing both .NET 1.1 and 2.0 remove the bug yet again... But (new info) removing .NET 1.1 and installing .NET 2.0 alone also results in the same bug. So standalone .NET 2.0 also causes the bug. As before, removing standalone .NET 2.0 removes the bug.

More than month ago I setup system based on A7V600. I included emule as well (owner is a polish guy and he said this is the most popular filesharing soft among Poles, thus he need it to get polish-language content) and as always I enabled ACPI/APM on this box. I haven't heard any complaints from him so far, last time we spoke his box was running smooth for 3+ weeks straight (emule). Are you sure? (edit: I fortgot this is 9x forum; I set it up with Win2K, perhaps thats why it works fine) Hi, 888! You are quite right! This ACPI/ACM issue is found only in Win 98SE and ME (perhaps also in Win 98, but it doesn't install it by default). If you deploy eMule with Win 2k or XP, you'll not see it (because it's not there, in these OSs).

Hi, Xstyle: RTFM! Relevant Excerpt from the "98SE2ME ReadMe Text Guide" found as html at http://www.mdgx.com/9s2m/read1st.php and as plain text at http://www.mdgx.com/9s2m/READ1ST.TXT excerpt begins --------- KNOWN BUGS + FIXES [...] * BUG: Active network/internet connection may stop working after installing 98SE2ME option 1 or option 2 on some computers connected to [uSB] xDSL modems and/or using (RAS)PPPoE protocol/drivers: http://www.raspppoe.com/ FIX: This BUG is not completely fixed yet! If you discover a fix, please post it here [thank you]: http://www.msfn.org/board/index.php?showtopic=46349 These are the only known workarounds: 1. Reset/reconfigure/reinstall/repair TCP/IP protocols + Client for Microsoft Network either from Control Panel -> Network or by using one of these free(ware) repair tools: http://www.mdgx.com/fw.htm#TCP 2. Run these 2 commands: IPCONFIG /release_all IPCONFIG /renew_all IPCONFIG.EXE should exist in %windir% [usually C:\WINDOWS]. More info @ MSKB: http://support.microsoft.com/?id=314850 3. If that doesn't work, restore these Windows 98 SE system files [%windir%\SYSTEM = usually C:\WINDOWS\SYSTEM] from setup CD-ROM or CABs or BACKUPS if you selected to backup your entire OS before installing any 98SE2ME options [the 1st time]: CFGMGR32.DLL CFGWIZ.DLL FINSTALL.DLL INDICDLL.DLL MSNET32.DLL MSPP32.DLL MSTCP.DLL NDSWAN16.DLL NDSWAN32.DLL NETAPI.DLL NETAPI32.DLL NETDI.DLL NETOS.DLL RASAPI16.DLL RASAPI32.DLL RNAUI.DLL SETUP4.DLL SETUPAPI.DLL SETUPX.DLL TAPI32.DLL CABL98SE.TXT lists the exact location of these files: http://www.mdgx.com/files/EXTCAB.ZIP How to extract files from CABs: http://www.mdgx.com/last4.htm#EXTRACT Certain %windir%\SYSTEM files MUST be replaced ONLY from native MS-DOS mode. How to exit/reboot into native/true/real/pure MS-DOS mode: A. Left-click the Start button -> click Shut Down... -> select Restart in MS-DOS mode -> click the OK button. B. OR hold down Shift + F5 at the same time during BIOS boot POST (Power On Self Test) sequence. C. OR scroll down using the down arrow to the "Command prompt only" option and then press Enter from the Windows 95/98 Startup Menu: http://www.mdgx.com/msdos.htm#MEN D. OR from a Windows 95/98/ME Emergency/Bootup/Startup floppy/CD/DVD/USB/external disc/stick/tape. Replace these files in small groups, for example start with: NDSWAN16.DLL NDSWAN32.DLL if that doesn't work, replace: RASAPI16.DLL RASAPI32.DLL if that doesn't work, replace: RNAUI.DLL if that doesn't work, replace: NETAPI.DLL NETAPI32.DLL NETDI.DLL NETOS.DLL ... etc. Reboot normal when done and then repeat (only if necessary) all steps at #1 + #2 above. Windows 98 SE system files [located into %windir%\SYSTEM] used by RASPPPoE protocol/drivers: ADVAPI32.DLL COMCTL32.DLL GDI32.DLL INDICDLL.DLL KERNEL32.DLL MSVCRT.DLL OLE32.DLL RPCRT4.DLL SHELL32.DLL SHLWAPI.DLL TAPI32.DLL VERSION.DLL USER32.DLL excerpt ends --------- HTH

Hi, soporific! Two interesting freeware add-ons are: Calendar 2000 http://www.gregorybraun.com/Calendar.html and a nice DirecteX Starfield Simulator Screensaver http://www.hope.co.nz/projects/stars/ Note: despite what is said in the above homepage, I found out that if you set up a screensaver password, it will ask for it normally on wakeup and won't let you get back to the desktop, unless it gets the right password, so it seems to be fully functional to me. Of course, I'm aware that their Win 3.1 couterparts do work under Win 9x/ME, but they require a licence for Win 3.1 (which I do have), while the above don't. They also have some more features, and the calendar has a beautiful interface, IMHO. Even MS at last has acknowledged that a simple calendar is useful, as I read they've brough it back from oblivion in Vista, so I believe these may be timely suggestions.

Apologies accepted You are right, of course! My apologies I think I've had more experience with ASUS A7V600s, A7V400s and Soyo K7VTAs than is healthy, but they were rather popular around here, are pretty robust... and have issuses with ACPI/APM that usually go undetected because they mainly affect uptime... But, more recently, I've found a scenario where this problem is easy to detect: if one installs eMule, and it consistently crashes the system after about one and a half hour or less, this is also due to the ACPI/APM issue! But much easier to detect! Anyway, I think I've had more bad experiences with ACPI/APM than would be my fair share...