ShadeTreeLee

One turn deserves another back - you can have makefile work for you too. Get the 3.1 from the org site and install it. Replace TASM file with 4.1 version like I did and you are set. Just type in MAKE, which will then launch and load MAKEFILE and run from it launching both TASM and TLINK - boom ya done. I couldn't get that to work with any other installation of C++ either. I did have to modify the last two lines of the MAKEFILE for aefdisk though since they tell the system to delete *.obj and aefdisk.exe. I kinda wanted to keep those around long enough to use them !! This version is where the 5.1 TLINK is from that wants a DPMI manager and apparently it's in here as it doesn't complain about not having that anymore. Read more about XP install first and then 98 after here http://www.dougknox.com/xp/tips/xp_repair_9x.htm I know it's backwards to the normal way to do dual boot with XP, but my network printer can only install from Drive C and XP wants to run the network, so my hands are kinda tied there. 98 will have to live on another drive. Loew has already sold me the memory patch, I was thinking the SATA driver was from another source but will look around and find out, thanks. I'm writing this on a Dell Dimension 2400 dual boot XP/98 box right now - it's where I do the TASM stuff at. It's PATA so no extra drivers needed there, the HP is SATA and has no emulation for PATA so it must be a genuine SATA driver system for 98 or it can't be done. Insane part is that it has a PATA CDROM drive on secondary IDE channel, but one can not ever have a slave drive on this cable, it won't work, can't work. It already is SATA/PATA half and half except it's topped out at three drives. They spend all their profits castrating these machines so we can't live without them. Dell AND HP AND Xerox. So I have this dual boot XP/98 system where metapad v2 says the line with the first error in aefdisk.asm file is at 2756 and when you run the same metapad v2 in XP instead of 98, it correctly says the line is 2743. What is going on here? Is this the only troubles I've ever had? Metapad? Is there some ansi 98 thingy that I didn't install that would make it do these kinds of horrible things in 9x and fly straight with XP? I can't even remember what my problem was at this point. I am able to compile aefdisk at full throttle and I wind up with a file of the exact same size but with one byte different. Comparing files C:\TC\His\AEFDISK.EXE and C:\TC\My9\AEFDISK.EXE 0000001F: 71 50 I don't think this makes a critical difference at all. This is with TASM 4.1 and TLINK 5.1. With version 3 TASM no errors with orginal asm file, but some dozen different bytes scattered throughout. With 3.1 I get: *Warning* aefdisk.ASM(2743) ":" operator ignored So DOS can count lines correctly - why can't metapad? This file also same size with the exact same dozen or so differences throughout. I'll use 4.1 with the 3.1 org package that has a working MAKEFILE system. At full throttle. What do I do about metapad? That seriously bent my brain.

Drugwash- I thought I did try that angle with no joy, but a batch file would work much better and I'll try that, thanks. But IIRC, the switches come first followed by the filename (with NO extension) to be worked on for those following along at home. TASM 3.1 only needed 3 passes so m9 switch is overkill, the other switches are default modes anyway, again IIRC. What I did find odd was that when I went to verify the error codes from before, now they don't match. It's as if aefdisk.asm has grown by x amount of bytes in the middle to such an extent that the error lines with fixes are no more to be found at 2743, 2919, and 2921. The code with fixes are 20 something lines higher and the line numbers agreed upon by all three of us now contain lines that are NOT those that were fixed. So while I'm trying to figure that part out, I can't replicate it again. Just leaving even more confusion upon the growing heap of it I already gots. But following that angle on out a ways, it's easy to see that if in the process, some code snippet was replicated within the .asm file then it sure would stand to reason that the results would be bigger. His 20 Kb, mine 21 Kb. There also should have been warnings about duplicate labels I would think, but my thinker has had quite a workout lately and can no longer be relied upon. I'll let the dust settle some first and then plug away when I can. If I ever find the why of mine being larger and it's actually important, I'll drop back in and post about that, until then, I'll just use shae's version with lots of gratitude. Thanks, everybody. Here is the batch file I used to do a 750 Gig SATA drive with, wound up with a 195 gig NTFS partition in fourth place. Halfway wanting to dual boot this with 98 on the second, but not sure I can locate all the drivers I need for the HP dc7600 it's going to live in. Need 98 SATA support to start with. XP on drive C. aefdisk 2 /show pause aefdisk 2 /delall /show pause aefdisk 2 /nolimit /pri:200000:c:1 /show pause aefdisk 2 /pri:20000:c:2 /show pause aefdisk 2 /nolimit /pri:300000:c:3 /show pause aefdisk 2 /pri:0:7:4 /show pause aefdisk 2 /deactivate /show pause aefdisk 2 /activate:1 /show pause aefdisk 2 /nolimit /formatfat:1:Drive_C /show pause aefdisk 2 /formatfat:2:Drive_D /show pause aefdisk 2 /nolimit /formatfat:3:Drive_E /show pause As per previous report, only Drive_D is labeled as DRIVE_D. /show works here just fine, but not with /label:#:name command. Didn't test it with /show first but that may work after all even though /show is listed as a command and not a 'goes first' switch. /nolimit switch made no difference on /formatfat commands, I have them here just to show I tried it, I tried it both ways - still no drive label under /formatfat command when partition is >137 Gig. End of the day, I'll set it up differently than above due to active partition flag issue. Have to delete the first slot partition after the second is installed, then do /mbr on it after formatting it. Then redo the first slot and finish with the last two slots, then deactivate all, then activate 1 and 2 slots and it should boot the second partition after XP installs it's boot manager in slot 1 which I then mangle with DOS mode debug script to give me a choice menu at boot up that includes 98 on drive D. Then instead of installing 98 to C:\Windows as per usual, I enter instead D:\Windows and 98 does just that and loves it. That's the plan anyway. /mbr operation being essential to the linking of boot sector to future home of 48 bit LBA aware io.sys. /mbr operation is not steerable (why not?) and must have an active partition flag or the linking doesn't take place. No link, no boot. Yes. I'm with you, but I had an .asm file stepped on right in the area of said not really code errors. Mighty fishy to me, I'll revist this issue for sure before hollering wolf, but I'm packing ammo just the same. 2nd time around I'll be looking for size changes in .asm files too. I could have looked the first time it happened, but the concept of it hadn't dawned on me until after I had cleaned the slate. Hearing you loud and clear again, but that first one is the understatement of the year for me - I haven't found two matching since I noticed that I maybe might should be using them even somewhat close !! And at least one doesn't play at all if it can't find it's friend. Where he can be found is something to watch for too. Oh, boy. A long time ago this Rockwell outfit published a 10 pound manual on what was what and how all 6502 assemblers in the future were to behave in ALL such manners as you explain to avoid such discussions as this one, and no one has listened to the word of that particular God ever since. Long story short, it is what it is. I can see how the colon could be essential for that on these processors, but in 6502 work it is part of the label name as it's shown to be so in the cross reference essentially just cluttering things up there. The delimiter for labels there is first space character, op code then is any line starting with a space or a space after a label. Really hard to debug this kind of source so sometimes it's two spaces required, but not always and round we go again. This ride just does not stop. I yeild. Because each of these quirks can be made to be darn handy and very useful in very clever ways. Tom8toe, tom-auto. You guys need it for that purpose, I can see that much already, nice to finally know this one at least has a genuine source of need. Your camp may have inherited the question mark from us where it used to be a non-cross referenced short branch label separated by .LOCAL regions for question mark reuse (???? vs ??????) since we can't do long branches anyway - but that's a really stupid and confusing idea all by itself. We can still do that, but I've never seen source written in the last 30 years that actually does it. Evolving madness. The real excuse for it at least in our camp is pandering to lazy typists. Someone's 'must have' idea that really wasn't so much needed. I don't think code anywhere was ever written with such blinding speed and ugency as to miss the spacebar by one tap where two were needed. A pipe dream to write usable, bug-free code at speeds the lousiest keyboard can't keep up with. Well that's why I found one of those files then. I looked at it this stranger with a familar first name, but that's all I can really remember about the encounter. Now that I know what it's for, that will start to help a little, thanks. The stepped on .asm file may have been a result from the previous attempt where I wasn't throttling the CPU too, hazy confusion is also a factor - I shall endeavor to duplicate using this trick too. It's wicked evil when DOS mode does this at 3 GHz, that much I do know. And then I could forget all about that part?? I'll blame it all on no speed limit for the moment and see how easy it is to repeat those results. I know I stepped in it pretty fast, safe bet I can do it again. Thanks a lot guys, I wouldn't be at this point without you, but I have a few days lost to catch up on now.

Thanks Shae, I'll compare yours to mine as I had complete and super fast good results as soon as I cleared the other installations and put on the org based 3.1. Too easy, I couldn't believe it. During testing of mine, it does require the /nolimit switch to be in front of /pri:200000:c:1 switch to get a FAT32 first partition of 200 Gigs. Otherwise it resets the size to 127 Gig as per normal. My possible bad on advice for TASM32 as the documentation says it's primarily for creating 32 bit debug information and does not suggest it's use for 16 bit work at all. I had read somewhere that it can serve dual purpose 16 bit and 32 bit work, but I haven't seen that in the documentation yet, so better treat that as fringe advice at best. They do the question mark in atari cross assemblers and it does bug me too, but then so does the colon in label names which you just glided over as not much at all. I'll just have to get used to both it seems. I have 2744, 2920, and 2922 written down in front of me, and that due to a blank line I inserted to attempt to get around the label problem on line 16, I saw a similar label equate line not too far away and he had a blank line under it so I'm thinking maybe that's it. I didn't go back to correct it when I found out that wasn't the problem. I tried to use the makefile but 3.1 didn't want any part of it as one of the C++ installs I tried would use it. I just did TASM aefdisk and I had zero errors and an .obj file which I then did TLINK aefdisk with and there was aefdisk.exe pretty as you please and just that fast. One thing I did do different was to lauch Throttle 6 with autoexec.bat file to slow DOS mode down from 3 GHz - I've had that problem during the making of vmm32.vxd during 98 installs and forgot completely about the issue in earlier attempts. DOS was never meant to fly that fast methinks. Much better documentation with 4.5 and 5 versions of C++, reading about where you can make a big swap file expressly for the use of these 16 bit borland programs such that very large projects can be done in the limited memory environment DOS has. Since you didn't report problems with line 16, 43, 44, and 472, I'm thinking we lay them at the foot of the GigaHertz god for a sacrifice? Throttle may have eliminated those errors entirely to wind up with exactly the same problems you went in and corrected the code on, nice work, thanks for showing us what was wrong and the straight forward way to write code. Obviously 3.1 is buggy in that it allows such errors so no real need to keep it around. To the best of my knowledge they quit making 16 bit TASM at version 4 something, as I stated before one 5.3 package had version 3 in it, which makes me anxious to see what is in the 4.5 I have when I get around to installing it in the correct manner this time around. I can't believe the prices they want for this 4.5 CD - I got it as a throw away so many years ago I can't even remember when or how. So a bit later than the above, I have tested both mine and yours. Mine is bigger for some reason but it still works, just like yours does. There are other bugs with it though, it won't make a label on /formatfat:1:Drive_C command but will if the partition is <137 even if the /nolimit switch is before anything else. So we have bad switch handling inherent in this to start with is my assumption and this is verified by using /show in combination with /label:1:Drive_C where it won't show afterwards as well. Lower case is kludged to upper case for drive labels as well. Installing 4.5 correctly got me the exact same situation I had before - no TASM with this at all. TLINK version there is 7, can I assume that even borland couldn't keep their act together at this point in time? Using transplanted TASM 4 with it results in a larger build than yours as well although I didn't do a file compare with the 3.1 build, so I'll have to do that someday. Looks like I'm on the hunt for borland C++ 4.02 CD release. Attempting the build with TLINK version 5, it want's a DPMI manager file to be loaded and errors out when it can't find it. Version 7 doesn't do this but my build is bigger than yours for some reason there - I assume it's cross versions of TASM and TLINK until someone straightens me out on why my end product with 3.1 and 4.5 kludge is bigger than yours.

Yep, I was thinking the same thing many times, but i'm on the trail like a houndog now. It's 3.1 and it's out there, if you'll go to the org site after searching for 'Borland C++ 3.1'. So is 5.3 but it has version 3 TASM and if I used 5.3, TASM is going to be under the BC5 path. Makefile has borlandc as part of the path and I read about that connection in the 4.5 text files on my CD finally pertaining to proper upgrading which appears to be wholesale directory deletion until you get to 4.5 and then it's a file list to back up, do this, and do that. Like being tossed into the deep end of the pool to learn how to swim, I think the 4.1 version I got on the web has been stepped on and just doesn't work right. Kinda odd version 5.3 is still using version 3 TASM to me. It also has TASMX for Windows DOS box and from there they go to TASM32 but it can still build 16 bit code if you link it with TLINK, which also comes in 32 bit flavors if that is your bent. As to my problems with no TASM in 4.5, well that's because I installed the run from CD files which don't do the 16 bit stuff. Needed to navigate to the folder where CMD16.PAK is at and run that install executable and then I would have gotten TASM just like that. I see 5.3 is built exactly the same way too. And I might still do that after I clean house and put 3.1 on there all alone to do this with. Jeeze, if I can do this is there even a need to post it when done? Further info here for those stuck at too high a version: A) Installing over previous versions of Borland C++. As a general rule, it is not recommended that you install Borland C++ 4.52 over any version earlier than 4.51. It is recommended that you delete the Borland C++ directory tree (BORLANDC if you have Borland C++ 3.1, BC4 if you have Borland C++ 4.0, or BC45 if you have Borland C++ 4.5) prior to installing. In addition, you will need to delete the following files in the Windows directory (WINNT under NT, WIN95 under Windows 95): owl.ini, bcw.ini, borhelp.ini, openhelp.ini, winsight.ini, workshop.ini. If you are installing over Borland C++ 4.0 or greater, you need to backup the RTL BIDS and OWL .DLLs prior to deleting the directory tree. Otherwise, any applications which need to link these libraries at runtime will need to be rebuilt. If you are installing over a previous installation of Borland C++ 4.51 or 4.52, you need to delete the Group file for Borland C++ (Under Windows 3.1, this is WINDOWS\BC45.GRP). The installation program cannot properly create this file if it already exists on your machine. I got that error prone 4.1 TASM in a version 5 bundle, and then found a better 5.3 bundle. Kinda curious what's in 4.5 now, but that will have to wait until after some sleep and some housecleaning.

Thanks for that anyway, it really does help as I'm stumbling along pretty good considering my entry level knowledge here. 4.5 is a no go as it lacks TASM, so downloaded 3 something package. I'm getting four errors, two of which are the include files which I'll just cut and paste into the .asm file, if that sort of end around will suffice. What it doesn't seem to understand is a couple of label lines. MBRloader label - this is an error where dataend label - isn't WTH??? and then this is the other error that makes no sense to me right off: wildcard? db 0 ; if HD number is '*' and right in the middle of a bunch just like it - I have no idea why that one could be wrong. I'll keep plodding along though, perhaps a higer version of TASM is in order? I've checked for multiple label definitions and I can't find any, unless they happen to be reserved words I'm out of guesses for the moment. Maybe ten passes could be tried instead of 9? We have TASM for cross assembly to the atari 8-bit believe it or not, but I've never used it there either, I kinda doubt it's a borland product and the name is the only thing ripped off there.

Since mid April of this year, one of my favorite DOS programs has gone open source on github. A re-director link will take you there from aefdisk.com. Only trouble now is that the only version of this program that supports large FAT32 /nolimit switch (>137 GB) is the open source one and it's zip file doesn't include the executable, just source code for it. "Needs Borland C compiler/linker for DOS" which I never learned how to do. I do have Borland C++ 4.5 installation CD, will this get me there? I don't even know this much about compiling PC code, my 'code' expertise begins and ends with the atari 8-bit. Anybody who knows how might go ahead and do that for the unwashed masses here? Provided this request meets with moderators approval in the first place. A yes or no nod would be most appreciated first as I truly intend to affront no one. But especially the moderators. TIA one and all.

Look for your SUWIN error number in the log file and/or the last few lines logged is where it died - what does it say? And then you should have copied those files from the USB drive further onto the hard drive so they would be found in the second portion of the installation process. Big mistake not doing this and then running the setup executable from the USB drive instead of the hard drive. That's two really big mistakes. You won't get USB 2 from DOS mode working IIRC, at best all I ever heard of was limited USB 1 with 9x. Up to you to find even USB 1 in DOS mode commands as I know nothing of it. Seems like you would need those specialized driver files on the hard drive in order to install and use them anyway. AFAICT, time to pull the hard drive, use another laptop to format it with system files so it can boot DOS, and copy ME files to it, put it back in this laptop and this time around be sure to have the USB drive in your pocket when running setup.exe. Or put in a floppy or CDROM drive and start all over as well. Ya killed it real good though, if that counts for anything. Believe it or not, I came up with a goose egg searching this forum. All I could get before google went down.... http://hddguru.com/software/2006.02.09-USBASPI-MS-DOS-Driver/

Yeah kinda. You should extract both files into a folder using WinZip or extract.exe in DOS mode and then right click on the inf file which will give you the 'Install' choice in the context menu. You then select that choice which then launches the inf installer engine which reads the inf file and follows it's directions as to where to copy the files to and what registry entries to cook up thusly installing the file. You know you got it when you see the entry to uninstall it in the Add/Remove Programs list. One of the first tips I gathered from the Internet was how to do all of this using a batch file - from PC Forrest, an ancient guru, anybody remember him? rem setup.bat from PC Forrest rem for %%1 in (*.cab) do extract %%1 /E choice /c:d /td,1>NUL for %%2 in (*.inf) do RunDll32 advpack.dll,LaunchINFSection %%2 echo off cls make that a batch file and put in the same folder with only the cab file. It would be best if the folder was a simple named one in the TEMP folder so that complications surrounding long file names are not then a problem. Then double click the bat file, also simply named. And then look in the Add/Remove Programs list for the new entry. I added the time delay via choice.com since I did run into problems where the extraction wasn't completed before the inf tried to launch which of course doesn't work out too good. More inf file help in the help file from WillyPad (direct link 392k). Which is a kinda supposed to be a NotePad replacement deal, but has some wild INF file writing helpers like importing .REG files and translating them into inf file lingo ready to use. I use it for inf file work alone, metapad is just too good to not use for the way too weak notepad replacement. And WillyPad is not a real contender either, sorry snoopy. Snoopy used to have a web site, but no longer.

You mean this? http://download.windowsupdate.com/msdownload/update/v3/static/rtf/en/5576.htm As you can tell the servers still have the files and they are still working, but this is one that I did not get a direct link too since it was worse than worthless even when the WinUP site was working for Win98. All it was was a bot that ran the site's scan in the background eating your bandwidth and if you needed anything at all, no matter what you thought you were doing today - Bam there you were at the WinUP site downloading and installing the latest update no matter what else you had in mind. And since most of them needed a reboot, what ever you had got done was at the very least interrupted. Since the site doesn't work anymore, there is no scan to run so you would not be able use Internet Explorer without it spending all it's time on this pointless quest endlessly. Dumb as a box of hammers. You can have my copy, it will need to be installed using the right click install choice when you right click on the enclosed .inf file. Uninstall via Add/Remove Programs under the name of Microsoft Windows Critical Update Notification. And if you're scared of the file you can always check it's right click properties for the expired Microsoft Digital Signature - I haven't figured out how to fake one of those just yet. There were only a couple of .cab file updates for 98, the rest were IExpress packaged executables again all with digital signatures just for the squimish. Saved from the Catalog site when it WAS working: com_microsoft.windows98andwindows98secondedition\x86Win98\com_microsoft.CUN_40_98_recupd_5576 cun.cab

Both. After making sure that you have the latest versions released in cumulative IE updates from MS you then register them so that "they" as a group know which other ones are around and playing in the same puddle with each other via registry entries made during registration. Among the various cumulative update packages released, MS would move a function from one file to another, most often due to a buffer overun exploit in same said function and unless they all were changed out together (as a cumulative package), the problem function could get lost or duplicated (neither of which are desirable or functional). Most of the files will fail to register as they don't have the capability built into them. But no harm is done trying all of them - those that do have the capability will and those that don't won't. Most files that do, will say so among their right click properties sheet under the Version tab and "other version information" section. Look for an entry that says OLE SelfRegister. If it's there, that file can be registered via Regsvr32.exe. http://support.microsoft.com/?kbid=249873 http://support.microsoft.com/?kbid=207132 A common mistake in the thinking process involves not using the latest update files because since you are NOT using IE at all, it shouldn't matter, right? FATAL error there - the files are there, they ARE being used by the OS and CAN be used by published methods to take control over your machine away from you entirely. Without you knowing about it in most cases. This was gospel while 98 was supported but since it isn't anymore we are always vunerable to published exploits anyway, the only thing we can do about that is to make them a smaller number of exploits by using the last update available. WinUP site is no longer working for win98 users, but links to direct downloads seem to still be working. The last IE 6 SP1 cumulative KB916281 for example: http://download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/IE6.0sp1-KB916281-Windows-98-ME-x86-ENU_39e4cfd60d6b77424d640afab75c3a5.exe It's name in real life is IE6.0sp1-KB916281-Windows-98-ME-x86-ENU.exe For 6.0 SP1 OE the last cumulative was 837009: http://www.microsoft.com/downloads/details.aspx?FamilyId=925628BD-1B5F-4B21-8DB6-EDE1C73F97B5&displaylang=en I too am thinking about using Opera, with IE 6, I get run off like a curr dog regularly (we only built the friggin internet as it is today with it and this is the thanks we get for that). Very interested in your results and issues. Is OE borked by 98lite? Last IE 5.50 SP2 updates are: IE http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8561 OE http://www.microsoft.com/downloads/details.aspx?FamilyID=ac1a8632-8b71-4d90-beb0-8c3f1a23889d&DisplayLang=en

I would suspect that the first meg of missing memory is due to the DMA buffer taking 64K. Further missing memory might be similar buffers relating to USB functions in a similar manner? I noticed my missing meg when I first achieved a working DMA buffer some 10 years ago. You might need a reminder that 95 shipped with broken busmastering as did 98. In order to fix it one has to modify both MSHDC.INF and DISKDRV.INF and then use them to install Windows with. Otherwise your DMA isn't working as it's supposed to. But I doubt that very much. I believe that motherboad makers were beside themselves when this fiasco happened with 95, they did not stand by doing nothing while 98 came and went with nothing fixed by MS. So they took it upon themselves to provide their own fix to the busmastering problem. They arranged it such that no matter what MS did or didn't do, DMA would work and work good without Windows to hold it's hand. Most motherboards do this. Mine doesn't, Chaintec 5ttm1. I require a wake up call to my hard drives while still in DOS mode at every boot in order to enable DMA transfer or I don't have it and I have horrible data flow without it. Including errors in DOS mode which has lead to many, many installations of Windows before I got the DMA thing straightened out. Not so many Windows installations these days. And one very real reason that the so called 'vxd.fix' actually worked here and worked really good too - my DOS loaded files are often corrupt due to less than stellar performance of my DMA system. Rather my non-DMA system. But as soon as I had an honest to goodness DMA buffer and it was working - I had one meg less of RAM as reported. http://www.mdgx.com/98-2.htm#W98DMA

My similar run in with MSBatch.inf was fixed by setting EBD=0 which then allowed the EULA to not show. Which then caused the default given product key given in MSBatch.inf to be used as designed. Don't know why, don't much care since the 'science' of it all seems to really not be documented or bug fixed to any real extent **IF** what I did allowed me to finally do full hands off installs of win98se full retail. And it did. I later came up with an inf file that "installed" the EBD folder with files that you don't get if you have EBD=0. There is a [EBD_CopyFiles] and [EBD_CopyFiles2] section in MSDOS.inf that covers the files concerned. My ProductType is 101 and I haven't yet found where it comes from. But the retail disks say "for PCs without Windows" and are NOT bootable. OEM disks are bootable and do say "For distribution with a new PC only". Keep after it and you will get it eventually. Biggest tip I can give is to add a line to MSBatch.inf to copy itself to Windows folder where is was designed to work from as soon as possible. Or change the paths in the file to match where it's at.

What is happening is you are running into .hta files that force the web view upon you. They are named folder.htt and they need to be deleted with extreme prejudice. The only allowed folder.htt file should be in the Web folder if you have one. Use Find Files to find them, select them and right click delete them conveniently. Also guilty are desktop.ini files but some are neccessary so wholesale slaughter of those is NOT recommended. You need them in TIF, History, Cookies, Fonts and other 'special' Windows folders, but not in Windows folder or Program files folder - delete them too. If you REALLY MEAN it - delete and it goes away like magic. It DO, it DO. With one explorer window open, set it to the way you want it and close it with the X in the upper right corner and with Ctrl pressed. This causes the registry to record what the settings were and the next time you open Windows explorer it should be the same.

At the MS Catalog site, last I knew, one had to be using win98 in order to see and then select the win98 archive. You also need to using at least IE 5.50 SP2 or IE 6 as well. Javascript has to be working along with ActiveX and you want to select "Find Microsoft Windows Updates" in the left panel in order to get to the catalog section. You don't need to wait for the opening site to "determine" if you have proper software installed, you won't be using it anyway. The old corporate site for win98 hasn't worked for years, they didn't have the latest updates there either. I am not clear on what you mean by "the corporate command for windows update is not working", which is obviously a lanuage problem. http://v4.windowsupdate.microsoft.com/catalog/ The Catalog site is the only MS site that I know of that has the latest win98 updates available for download and saving to CD or other storage media. They appear to have Portuguese BR as a language choice and several updates for download. And then there is this alternate to the old Corporate site, in english. But I can't see my way to the equivalent page in Portuguese so one may not exist. I do seem to recall several language versions available from the Knowledge Base articles quite often if that helps any. http://support.microsoft.com/ph/1139 That's all I have on the subject any more, hope it helps...

Oh, yeah. About the ASPI.inf file, on the last line where you delete the WarnVerDLLs warning... You don't have to do it that way. What you can do instead is just install the different aspi files and then set the SetupProgramRan key to a value greater than zero and at the next bootup Windows will run a NEW checksum entry on the files you just installed and then start using that information to "protect" those listed dll files from ever changing again. This is all it takes: HKLM,"System\CurrentControlSet\Control\Shutdown","SetupProgramRan",0x00010001,01,00,00,00 and a reboot. The SetupProgramRan key causes this behavior but I haven't figured out yet how to do the same thing over in the CheckVerDLLs list. I'd love to know how to add one in there and have it calculate it's own binary string entry in a similar manner to the WarnVerDLLs list. Somewhere, somehow it sure enough happens though.