dencorso

Are you sure? Did you read my posts about system.cb in safe mode? They are here: http://www.msfn.org/board/more-than-win9x-safe-mode-t142953.html If my solution works for safe mode, it can be more useful than binary patches. @Usher: I've read it, rest assured. Your solution may well work. I have not tested it, nor can do it easily, because nowadays I use the RAM Limitation Patch, which I deem the best solution. It gives the system much more stability than any of the free solutions and access to all the RAM. Since I've got no experience with your method, I cannot recommend it, although this does not mean I'm implying it doesn't work. I simply never tried it, and, as far as I know, nobody else did, since you posted it. But I'm willing to add your thread and your machine to the > 1 GiB list, provided you PM me the description of your system, in the lines of the descriptions of the machines already listed there. But using xRayeR's patch is very reliable, and has been thoroughly tested by many users. Xeno86's modded VCache.VxD and xRayeR's modded IO.SYS are perfectly safe, there's no need to be paranoid about them, and they obviate a lot of work. I recommend doing the following (read this as a Mini How-To), which works for both Normal and Safe Modes: 1) Adding a "MaxPhysPage=48000", without the inverted commas to the [386Enh] section of C:\WINDOWS\SYSTEM.INI 2) Installing Xeno86's modded VCache.VxD (after this, usually, no MaxFileCache line is needed in SYSTEM.INI) 3) Adding HIMEMX.EXE to C:\WINDOWS, and then renaming it to HIMEM.EXE 4) Applying MS KB311561, then rebooting. 5) Running xRayeR's w98iopat.exe, in True DOS, from C:\ 6) Creating a CONFIG.SYS in C:\, containing the single line "DEVICE=C:\WINDOWS\HIMEM.EXE /NUMHANDLES=64", without the inverted commas. For even better results, one should instead use RLoew's RAM Limitation Patch, of course, but that's not for free, and the above procedure is the most reliable way to do it completely for free, in my experience.

Welcome to MSFN!

Welcome, Bracamonte! Hope you enjoy your stay!

1) you need to have a non-empty config.sys to be able to work with minimal reliability with > 1 GiB RAM 2) the config.sys must be in the root directory of the boot partition. 3) it has to have a line for HIMEMX.EXE (*NOT HIMEMX.SYS) or it'll use HIMEM.SYS by default. 4) HIMEMX.EXE and XMSDISK.EXE should be loaded from config.sys, not from the command line 5) to access "Safe Mode" with > 1 GiB RAM you'll need both the VCache.VxD modded by Xeno86 and xRayeR's patch to IO.SYS. 6) I'm trying to help you, but if you omit information (like the fact you were offering us the configuration files from C:\WINDOWS\COMMAND\EBD, which are irrelevant here, instead of making it clear you had no config.sys on the root directory or that it was an empty file), then what is already not very easy becomes impossible to do.

Sure. Not KernelEx but something like it. BTW, there already is something like it for Win 2k... its called KDW. Look in the NT/2k/2k3 forum for more info.

@Prozactive: You're very welcome! @duffy98: Well, Prozactive already answered your main question. Let me answer the minor one: Microsoft's (and many others') version numbers are always in the format xxxx.xxxx.xxxx.xxxx (for more about it see this post, by Petr) However, when you look at them through the right-click -> Properties menu -> File version, in many cases, when one of the nuber groups is "0" it is omitted, for some reason... Thus 4.10.0.2225 is, in fact, the same as 4.10.2225. In the fileset from Win ME this is more visible, because most of the files are 4.90.0.3000, but there are some which are 4.90.3000.0, and either show simply as 4.90.3000, when you use properties. But when you use other programs to establish the file version, (like microsoft's filever.exe [KB913111, newer version inside this package] or getver.exe [link] by L. Brisar, or the MiTeC EXE Explorer), then you get to see those zeroes.

No, IE8 is enough! Both bugs are solved in IE8. So, for anyone annoyed by the bugs described in this thread, upgrading to IE8 is the only known solution. A great one, BTW!

Besides NUSB, LLXX's patched ESDI_506.PDR v. 4.10.0.2225 and that EXPLORER.EXE, I think these are the most fundamental updates to add to any 98SE installation: Unofficial SHELL32.DLL 4.72.3812.634 (Explorer Lockups Fix) [link] (do read also: PATCHED SHELL32.DLL BUG + FIX). Unnofficial KERNEL32.DLL 4.10.0.2226 (2-4 GB Files Errors Fix) [link] (this I think you already use). Unnofficial KRNL386.EXE 4.10.0.2000 (Stack Corruption Fix) [link].

It depends on the drivers. Most VxD drivers will work OK. The WDM support of SE is much better than that of FE, so there is where problems may lie. The best one to answer your question fully would be PassingBy, but he's been absent for a long time, now.

Glad you liked it. I find it quite useful, too. I have tried to find where the explorer.exe build 1710 of mdgx comes from, it has a header time stamp of 2/8/99, in contrast to explorer.exe in IE55SP2 and nusb, which have a header time stamp 1/30/99. i found some info here. <snip> But when I looked into the installation source of IE6 SP1, I couldn't find an explorer.exe in it. The MyComputer icon in mdgx-explorer.exe looks like from Win2k. Any idea where erpdude8 got this version of build 1700 from, with the later header time stamp 2/8/99? It's not from the IE6 SP1 at all, but from IE4.01 SP2! More info about it here.

Except in very unusual situations (for more about those, read this, this and this), you should trust the file version, not the file date/time (since an older build might have been recompiled later, or the file date/time simply changed to conform a given release). And, BTW, the EXPLORER.EXE you've got from MDGx is v. 4.72.3612.1710 (the latest known to exist for 98FE/SE), which is the one I also use for a long time now.

Either you get a modded BIOS that supports 48-bit LBA or you add a DDO. If you do neither, all your efforts will be wasted, sooner or later, unless you desist from using a > 137 GB HDD as the boot disk. That's all there is to it.

@Prozactive: Yes, I edited that post and added the info, but forgot to enable the "Edited by" field, which is not mandatory and is off by default for smods. Here's some additional info: (a) here's a noteworthy Symantec KB article (which however refers to Ghost v. 11.5.0.x). (b)for those interested in understanding the version history of Ghost (and the evolution of the program), there is a great entry in the Wikipedia about it: Ghost and this other Symantec KB article: Updates to Norton Ghost 2003 ©more about RLoew's 1 TiB patch...

Here's how to disable ACPI (and APM, if desired), in case you wish to try this idea.

I think you'll need oeupdate.exe to install it. You may have it in your system already. If not I can point you to it. Please, do list here the contents of the cab.

Unpack it with 7-Zip and run it yourself, instead of relying in MSIEXEC.

Let's start by doing some changes to your config.sys, and observing what happens: 1)Since you don't use EMM386.EXE (neither do I), there can be no UMBs nor EMS. So substitute: "dos=high,umb" by "dos=high" and "devicehigh=ramdrive.sys /E 2048" by "device=ramdrive.sys /E 2048" 2)However, ramdrive.sys is a very limited ramdrive, so let's use XMSDSK. So substitute: "device=ramdrive.sys /E 2048" by "INSTALL=XMSDSK.EXE 2048 /C1 /T /Y" You'll need to have XMSDSK.EXE at the root directory of the boot disk or if you prefer to have it elsewhere: "INSTALL=<path>\XMSDSK.EXE 2048 /C1 /T /Y", where <path> must be substituted be the actual path to XMSDSK and 3)Let's use HIMEMX.EXE, instead of himem.sys. So substitute: "device=himem.sys /testmem:off" by "device=himemx.exe /testmem:off" You'll need to have himemx.exe at the root directory of the boot disk or if you prefer to have it elsewhere: "device=<path>\himemx.exe /testmem:off", where <path> must be substituted be the actual path to himemex Here's a good reference for MS-DOS 7 Commands, in case you ever need one and links to get HIMEMX and XMSDSK are findable in the 1st post of the > 1 GiB RAM thread. Do all three changes at the same time, test how your system behaves and let me know. Our next move will be to solve the "Safe Mode" issue, but first we should establish that the modifications I just suggested either make your system more generally stable or, at least, do not render it less stable. Good luck!

What USB related options are there, in your machine's BIOS, under which tab and sub-tab are they located, and what value do they have selected at present?

Maybe the attachment system is disabled on this forum. It's happened before. Can any of you all confirm it? If that's the case I'll see to it that it gets reenabled. Please chime in. @krelian: instead of attaching uploade the zip to rapidshare or uploaded.to and post the link here. Don't forget to provide the machine's hardware info. When I have that, after musing over it some, I'll suggest you something. Meanwhile, do create a bootable CD or floppy with memtest86+ and run it continuously for at least 12h, to see whether your machine's RAM is OK.

You're far from having an "unusual" memory issue... And to access Safe Mode, some tweaks are needed. I never said that running 9x/ME with > 1 GiB RAM for free is a walk in the park! But I cannot help you on the meagre info you provided. Post a machine configuration like those you can see in post #2 of the > 1 GiB RAM thread. And attach, don't post, a zip file containing your AUTOEXEC.BAT, CONFIG.SYS, MSDOS.SYS, WIN.INI and SYSTEM.INI. Then we can try to help you do it.

My experience with Ghost 2003, like Prozactive's is that it's the best cloning program ever. It's very reliable. As far as I know, there's no limitation to the size of the destination partition used, except those imposed by the host OS, because the access for writing the image is done through the OS. Ghost only accesses the disk directly to acquire the image and to redeploy it. In any case, for DOS and Win 9x/ME, this means we can be sure the partition one saves the image to can certainly be as big as 1 GB (= 931.5 GiB), if not more. The anecdotal partition size limit for image acquisition is also 1 GB (= 931.5 GiB), if not more, too. BTW, GHOST.EXE for DOS from Norton Ghost 2003 is v. 7.6.0.793 (with cdrlib=3.1.25), when fully up to date... This means that Ed999's comments make little sense, since GHOST.EXE for DOS v. 8.3.0.1355 1335 (with cdrlib=3.1.31) is the most up to date version of the GHOST.EXE that comes with the SYMANTEC GHOST SOLUTION SUITE 1.1 (initially released in 2005), and hence is a later (and even better) version of Ghost. It took me some time to find it in my bookmarks, but there is this post at Radified, by Dan Godell, that you may find interesting. BTW, Radified is the place to go when one has Ghost in mind, although, of course, you're welcome to post about it here, too.

The only reason you didn't find good info is that you didn't search enough! There is info galore about Big HDDs and the 48-bit LBA limitation, both here in MSFN and elsewhre. It's not a matter of creating all partitions with less than 137 GB, it's far from that. You've already got both a 320 GB HDD and an old BIOS: you either take some proactive action (namely update the BIOS or get a DDO) now, or you're gonna regret not having done so later.

That thread fell into oblivion, sorry! Try this link, instead.

From the times of the original IBM PC (1981) to the present, it's a de-facto BIOS standard to have it pass control to any present add-on board BIOS extension, before it actually boots. That's the reason why the string from the video board always appears early on the boot process. I bet most, if not any boards should be bootable and BIOS hacks would be necessary only for very badly written BIOSes.

@Multibooter: I'm deeply sorry, but I have no alternative way to recover the lost content, but for those caches and the WayBack Machine for older content. I'll ask xper about whether perchance we have a full forum backup containing that post, but this may take a while, and I can guarantee nothing. Meanwhile I've put back in post #22 the two snippets of its original content findable throughout the present thread (the one you yourself provided and another found in post #23). They may be of help in recovering the full content of that post. I'm sorry not to be able to help more.