dencorso

Sorry about that! I've been using Plop 5.0 since incept time, and it never gave me grief. Since last year I'm using 5.0.13 to boot from USB pendrives in machine which BIOS don't support it. However, the first version to support PCMCIA is 5.0.14, which I've not yet tested. You might report your experience directly to Elmar Hanlhofer, he is very nice and much helpful.

Plop bootmanager.

No. He meant EMM386, QEMM, CEMM, 386MAX and NETROOM... because they are simple VMMs which run DOS in V86 mode, and have to be suspended in order for Windows own full-fledged VMM to take over, while leaving lots of things for Win VMM to take care of that otherwise wouldn't exist.

Set the test size to 700 MB, let the # of passes remain 5 and click on Seq, instead of All. CrystalDiskMark will tell you the speed (in MB/s) for read and write operations, selecting the best result out of 5 tries. It's simple like that. Now, what does it actually mean? Let's see (my tests were performed with a 100 MB file, not a 700MB one) how long it takes to copy a 100 MB file, here are some real life data: Sony Micro Vault 1GB (made in 2005): Sequential Read : 10.245 MB/s --> or (100 / 10.245) = 9.76 s Sequential Write : 6.198 MB/s --> or (100 / 6.198) = 16.13 s Kingston DataTraveler DT100 8GB Sequential Read : 23.211 MB/s --> or (100 / 23.211) = 4.31 s Sequential Write : 15.256 MB/s --> or (100 / 15.256) = 6.55 s OCZ ATV Turbo 8GB Sequential Read : 32.630 MB/s --> or (100 / 32.630) = 3.06 s Sequential Write : 26.449 MB/s --> or (100 / 26.449) = 3.78 s Corsair GTR 64GB Sequential Read : 28.587 MB/s --> or (100 / 28.587) = 3.49 s Sequential Write : 16.655 MB/s --> or (100 / 16.655) = 6.00 s Patriot Supersonic Magnum 64GB (in USB 2.0 mode) Sequential Read : 30.611 MB/s --> or (100 / 30.611) = 3.27 s Sequential Write : 27.303 MB/s --> or (100 / 27.303) = 3.66 s So, my good old Sony Micro Vault 1GB (which was razor-edge technology in 2005) takes 9.76 seconds to finish when I read 100 MB from it, while the OCZ ATV Turbo 8 GB finishes the same operation in 3.06 seconds (or in about one third of the time). And the same Sony Micro Vault 1GB takes 16.13 seconds to finish when I write 100 MB to it, while the Patriot Supersonic Magnum 64GB finishes the same operation in 3.66 seconds (or in about one fourth of the time). Moreover the Sony Micro Vault 1GB takes 9.76 seconds to finish when I read 100 MB from it, but takes 16.13 seconds to finish when I write 100 MB to it, so the write operation is about twice as long as the read operation. All this was measured with the same motherboard (Asus A7V600-x), and the same processor (Athlon XP 3000+ overclocked to run as a 3400+) and the same OS (Win XP SP3). See this results from a much l faster (SATA I) hardware ramdrive: GB i-RAM 1.5GiB under Win 98SE Sequential Read : 122.069 MB/s --> or (100 / 122.069) = 0.82 s Sequential Write : 120.388 MB/s --> or (100 / 120.388) = 0.83 s GB i-RAM 1.5GiB under Win XP SP3 Sequential Read : 132.878 MB/s --> or (100 / 132.878) = 0.75 s Sequential Write : 120.388 MB/s --> or (100 / 120.388) = 0.79 s XPSP3 is 9% faster for reads and 5% faster for writes than 98SE, both fully tweaked, for the same hardware and processor. Hence, write times are always greater than read times. Different OSes give slightly different results, with new OSes being faster. Different hardware gives different results, with newer hardware being faster, in general. What you did in your real-life example is, by far, the most unfair comparison, since you wrote (slower than reading) to your unnamed pendrive in the older hardware (slower) with the older OS (slower), getting the longest write time possible. Then you read it (faster) in the newer hardware (faster) under the newer OS (faster), and got the shortest read time possible for the same pendrive. As I said many posts ago, you've got an absolutely normal result. Moreover, the empirical (not theoretical) limit for sustained USB 2.0 transfers is about 35 MB/s (and I know no pendrive that really reaches it, especially for write operations), so, even if you acquired the bestest pendrive ever under the fastest hardware, CPU and OS possible, you wouldn't be able to do any 700 MB transfers significantly below 20 seconds, no matter what you do.

Why not use the single program that is known to work?

Here are two good book recommendations: Modern Operating Systems (by Andrew S. Tanenbaum) ISBN 978-0-13-600663-3 (not necessarily the 3rd ed., which is the current one) or, if you're much more technically minded, the book that enabled/inspired Linus Torvalds to create LINUX: Operating Systems: Design and Implementation, (by Andrew S. Tanenbaum and Albert Woodhull), ISBN 978-0-13-142938-3

The Mechanical Keyboard Guide.

The VGA has nothing to do with with the reported size or the limit. The Onboard VGA reserves its share of RAM for itself much before the time DOS boots, so by that time it aready is "not there". Nonetheless, part of it will be mapped within the System Arena and part at the A0000-BFFFF region of the Compatibility Arena of Virtual Machine #0 for Win 9x/ME. Real Addresses are the dominion of the VMM (and of the hardware itself). All that is there, from the POV of the rest of the SO and all other applications are Virtual Addresses. The Swapfile is part of the implementation of Virtual Memory, but its size does not define the Virtual Address Map, which is predefined by the OS, taking into account the CPU's intrinsic limits to address space. The full Virtual Address Space used by Win 9x/ME is described in Q125691 - INFO: Overview of the Windows 95 Virtual Address Space Layout. Now, in a nutshell, it's set like this (and divided in four Arenas by MS): You should, by all means, re-read Q125691, whence the figure above came, and also Igor Leyko's Article (in English, by GreyPhound) (link to the original Igor Leyko's Article in Russian). So, there are just so many adresses, and that's all. All things that go in the System Arena must fit within 1 GiB, else the OS must crash from lack of other options.

Grub4DOS

Dave, it's OK! Rest assured I'm sure your intention was not to mislead. That said, it's relatively easy to run safely Win 98FE/SE with up to 1 GiB of RAM (or Win ME with 2 GiB, having it recognize almost all of it). For Win 98FE/SE the how to is outlined here.

Here's two more that might come in handy in the future.WdfVersionUnbind WdfVersionBind And yet some more:KeReadStateEvent InterlockedExchangeAdd KeQueryActiveProcessors RtlUpcaseUnicodeString <-- although I reckon this one may not be feasible

If we want a strict definition, services are processes which run with a service flag. They can be shut down without killing the OS, but that comes at the cost of significant loss of functionality for most of them. You're both right. Now service tight interdependence and their being launched by services.exe or svchost.exe in most cases are characteristics of the NT-OS service model, and that is what people usually mean by "service based OS". The NT-OSes make extensive use of services, even when other solutions could have been used. But they're not truly service based, because they can be run with no services at all. But before attempting to do it, do get Superfast Shutdown, because you'll need it to either reboot or shutdown (unless you don't mind pulling the plug to shut down), after killing winlogon.

So we do agree on this point. BTW, v. 4.20 is still a VxD, right? It's from before he moved on to .SYS. Sure, I think that's what he meant, too. And it may be needed for XP/2k sooner than anyone expects... (But I'll let this discussion for a new thread in the apropriate forum, later on). It appears that he is not claiming ownership of the source code, only the name WDMSTUB, so it should be OK to use it and extract the later Code. Yes, that's how I understand it. And he *is* a lawyer, besides being a programmer, so I think he meant precisely what he said. I *think* that using another name, and printing a message telling something like "based on WDMSTUB, by Walter Oney", should be all that's needed. You rock, PROBLEMCHYLD! Your iniciative in contacting W. Oney was great, timely and enlightening.

Those are services, all right. But services or daemons (or whatever you may call them) are part of OSes since way back. They aren't inherently good nor bad. They are just OS tasks that perform their missions unobstrusively and without bothering (or interacting with) the user. On the NT-Family OSes, they can be set to start at boot time, at kernel time or at user time (= after logon), and if the latter, automatically, on demand or not at all... so, the NT-Family OSes gives the Admin a very fine control of how each service will run, and the developers liked it so that lots of things became services under the NT-Family OSes. Other OSes do have them, but sometimes in a much less standardized way. And yes, services are exploitable, as also are any other parts of any OS.

That's great news! What do you think about the question of whether is it preferable to have the WDM Function/Stub provider as a .SYS or as a .VxD which I've raised some posts above?

Great! Since you've contacted him, do please invite him to join MSFN. His participation in this thread would be much welcome and enlightening. And he would be a really great addition to our community, even in case he currently does not have an active interest in 9x/ME anymore. That would be best left to our programmers, like jumper or aru. I do have his book, that's how I first learned about WDMSTUB. Of course he shall have his wish respected. I propose the updated version, if and when we arrive at that, should be named "NUWDMST".

With all due respect to you, dw2108, your post above makes so little sense it reminds me of the Chewbacca Defense. 1) We're in 2012, so that "8 yrs maybe 9 yrs ago" puts us in 2003-2004. Now, at that time, the newest RAM was DDR2 (which exists as 4 GiB [very rare and now already out of production], 2 GiB and 1 GiB sticks), but the biggest one one could buy by December 2004 was 1 GiB . And the maximum size ever for DDR1 has always been 1 GiB. So, no matter what sellers pushed on you, if you limited your buy to a single stick, you couldn't possibly be forced to run "over a gig and a half" simply because no stick "over a gig" existed at that time to be sold. 2) Still today buckets of 512 MiB DDR1, 400 MHz (which can run below that clock), and lower clockrates too, can be easily found to be bought. 3) There's no way Win 98SE would run, let alone install, with 1 GiB, without adding a MaxFileCache statement to control VCache, in SYSTEM.INI. As everybody who ever attempted it knows, it bails out with: I could go on, but I think you've got my point already. This thread is dedicated to precise descriptions of how to run Win 9x/ME (like those on post #2), to help those those interested in doing it. Vague recollections can be misleading or even plainly wrong: that's the well-known Rashomon Effect.

Well... maybe. Many moons ago, Maximus-Decim himself tried (sorry, I cannot find the source for this info anymore): HKR,,NTMPDriver,,"wdmstub.sys,update.sys" (in machine.inf). What follows is my take of what happened, because MD himself is very terse: it sort of worked, but just for machines having Intel processors (even then, maybe just some of them), because update.sys applies only to intel microprocessors, if I'm not mistaken. Anyway, all this was gleaned from machine-translated Russian posts, so maybe I'm not quite providing a good report of the facts. More recently, MDGx attempted something, too, in usb20drv.inf from the pack having the same name. However his HKR,,NTMPDriver,,"WDMSTUB.SYS,USBSTOR.SYS,<drivername>.SYS" is not right, and doesn't work in practice... while it should be just HKR,,NTMPDriver,,"WDMSTUB.SYS,<drivername>.SYS" in both instances, I don't know whether it has been tested like this. Now that we're trying to go beyond USB Mass Storage devices, I think it may be worth the while of doing some rigorous tests. While USB Mass Storage devices were the only target, loading as a lower filter to USBSTOR.SYS was enough, and known to just work, so I thought about it no more. Quite recently, when working with USBSER.SYS, thanks to Drugwash's post about it, and also thanks to my recent interest in Bluetooth, and futhermore thanks to my discussions with PROBLEMCHYLD about the uSP, the fire was rekindled and fanned up, so here we are.

While SpinRite rocks, Steve Gibson's rants about security and his ShieldsUp! page should be taken with a real *huge* pinch (not just a grain) of salt, IMHO (and I'm not the only one to think so).

Nothing is different in the .inf. The fact that the sound card cannot possibly be removed while the system is running is what makes WDMSTUB.SYS remain always loaded. The thing is in the WDM model itself. While VxDs can be created to be unloadable, they can also be permanent. WDM drivers usually are unloadable (and I'm not sure whether they can be caused to be permananent, probably so, I would have to study this question some more). But, when one loads, as most of us do, WDMSTUB with USBSTOR, it'll only be loaded when a pendrive (or other USB Mass Storage device) is inserted, and then will be unloaded when it's removed. PROBLEMCHYLD and I just faced a situation where this can be a problem (well, sort of...) because the newer USBSER he adopted needs WDMSTUB. So, the situation created by this is the following: when one inserts a USB Mass Storage device, WDMSTUB is loaded, when one inserts another USB Mass Storage device, WDMSTUB is loaded again, and if, then, one inserts a USB Serial device, WDMSTUB is loaded yet again, and so on. This is harmless, but eats memory, so I think it would be nicer if we could avoid it. Now, in my machine, in which WDMSTUB gets loaded during start-up (by the onboard sound card, thanks to smwdmVI3.inf) and remains in memory, I found out I can omit WDMSTUB as a lower-filter for both (in the .infs), *because* it aready has been loaded by the SoundMAX driver, and provides the needed stubs for everybody else. So, it's more a question of saving memory and avoiding multiple, albeit harmless, loadings of the same lower-filter. Of course, the SoundMAX driver comes with an older version of the WDMSTUB.SYS, so I've just updated it to the newest version and compilation of it I know of. A more general solution, one that involves some intensive programing, but is general, would be to convert the current WDMSTUB.SYS back to VxD (and have it loaded from SYSTEM.INI).

You're welcome! Please feel free to do so. Many also do. That's the beauty of having more than one choice: more people gets happy. The only thing about SCANFRAG that is relevant for everybody installing it is that it needs Win ME DISKMAINT.DLL, instead of the one that comes inside it.

Yes. I know of at least 3 builds of v. 5.0.0.6, with different PE Timestamps. Of course, any of them is more up-to-date than v. 5.0.0.4, of which I know of just one build, the one that comes with the SoundMAX drivers. Sorry! I'm a native speaker of Portuguese, and despite my best efforts at expressing myself clearly in English, it sometimes shows. By "dispositive" I intended to mean gadget, gizmo, resource, device, but that's a meaning "dispositive" has in Portuguese, not in English. They are "false friends". So I was thinking about an onboard soundcard, or an onboard modem, or perhaps even an onboard graphics card... in any case, something that uses a WDM device driver, but which does not necessarily need WDMSTUB.SYS, and which cannot be removed, so that once the driver is loaded it also loads WDMSTUB.SYS, and it never gets unloaded, because the device cannot be removed. My own board uses the SoundMAX driver, so I do have WDMSTUB.SYS loaded all the time. But I'm talking of using any WDM driver, even one that doesn't actually need WDMSTUB.SYS, just to load it in memory and have it remain there.

Yeah, that's it. That's one of the motives I never recommend SCANFRAG. The other is I think it installs too many unnecessary things, while BHDD31 is spartan and to the point.

The Sisters of Mercy - Walk Away