dencorso

With all due respect, DosCode, what you're interested in are "CMD Scripts", not "DOS Batch Files". Your insistence in using "DOS batch" in the titles of your threads is misleading, so please do use "CMD Script" not "DOS Batch" for any new topic you start in the future. Thanks.

@jds: The Garmin drivers also contain a release version of WDMSTUB.SYS v. 5.0.0.6, but its PE Timestamp shows it's a complation less than one year earlier (and about 1 KiB smaller) than the one in NUSB3.0e, which AFAIK is the latest one available. The SoundMAX driver contains a WDMSTUB.SYS v. 5.0.0.4, which is not relevant, unless for study purposes. However it shows how to get WDMSTUB.SYS permanently loaded, by using it as a lower filter for a device permanently present, such as the onboard soundcard. This approach could be applied even for soundcards not needing WDMSTUB, just to get it permanently loaded, but cannot be generalized: one has to identify a suitable dispositive device in one's own machine and modify the apropriated inf. by hand, on a case-by-case basis. @jaclaz: Thanks a lot for the pointers! the D-Link stack seems promising enough for general use. I'll give it a finer look tomorrow and see what I can do.

Opera 10.10, runs OK without need of KernelEx (but don't forget to disable auto-updates asap, on the first run). It's the minimum one must have to get around the web. Adding KernelEx, and then upgrading Flash and Java, still allows to have a decently up-to-date browsing experience.

Try sysinternals strings.exe

Wishlist for a next version of WDMSTUB: _vsnwprintf HidNotifyPresence InterlockedPopEntrySList InterlockedPushEntrySList TdiCopyBufferToMdl TdiCopyMdlToBuffer ZwDeleteValueKey With those, there'd be a chance to add the Bluetooth stack to 9x/ME using MS files, although it's a long shot. Anyone knows of any Bluetooth drivers for 9x/ME, whatever publisher may it come from (I'd guess Widcomm or Blue Soleil)?

The above description contains one small error, which comes directly from the source (the same typo is actually present also in W. Oney's own instructions): It should be: HKR,,NTMPDriver,,"wdmstub.sys,yourdvr.sys" instead of HKR,,NTMPDriver,,"wdmstub.sys,,yourdvr.sys" Just one comma goes after wdmstub,sys, not two. I've attached the inf from the Garmin GPS (one of the products using it), taken from their driver, as a further example of an working installation of wdmstub.sys. I've also included an inf taken from a SoundMAX audio driver, which also uses wdmstub.sys, albeit it's a more complicated example. And, just to keep things as together as possible, here I quote another post of mine, from another thread. Well, the bible of WDM is Walter Oney's book, Programming the MS WDM, but his site has a lot of interesting info, too. This old version of WDMSTUB, when it was still a VxD, is also interesting. Then there is his classic article on WDM: Part 1, Part 2 and Errata. Enjoy! And a link for Walter Oney's WDMCheck page. There! I think now we have all info that's needed together in this thread. inf_archive.7z

Welcome back to the fold, the_guy! It's really great to see you around!

@jds: Congratulations for your good and comprehensive sleuthing! I'll just add two small bits of info, to make it easier for those looking for WDMSTUB.SYS. (i) W. Oney's book's floppies only provide the debug version of WDMSTUB.SYS ("checked" or "chk" in MS parlance), which is ~20 KiB for v. 5.0.0.6 (the latest). (ii) NUSB30e includes the release version of it (without debugging information inside), which is ~13 KiB for v. 5.0.0.6 (the latest). While both work equally well, the release wastes less memory, because its smaller. All versions of NUSB can be found here, of course.

Yes. gerislamico provided an interesting example of 161, but adjusted to the lenght of the 157 and with "98", not "95". I think larryb123456 should be contacted and the original 157 and 161 bmps provided him, so he could come up with some killer bmps for both 95 and 98. Once we have that I'll gladly create patch patterns for helping anyone interested in replacing them in some flavor of the "1700" explorer.

Well if you don't want to use an operating system based on services, don't use any 9x flavor either as it's also based on services (which are provided by a myriad of vxds rather well hidden from the end user and which make the core of the OS). Is this correct? Are the hidden vxd services the equivalent of NT services which run visibly as exe? No. VxDs are drivers, not services, although there can be dinamically loaded and unloaded VxDs, but that doesn't make them services. Now, LINUX daemons *are* services. And no, VxDs are not hidden at all: all one needs is APSoft VxDView and they'll be in plain view whenever one wants. BTW, @loblo, is the red part of my quote of your post actually a quote? If so, whence? Please do not quote silently, it's confusing.

Those who don't use KernelEx (like myself) actually also won't have any use for PrintDlgEx, AFAI can see, though... As for you getting KernelEx to compile correctly, that's the first priority, all right, IMO too. However, the source, when available (and in the Win 9x/ME world it almost never is) does help devise patches better too, but you don't need to agree with me about this, since here YMMV.

I don't see that as a viable goal. We're not competing with XP and Win 7 or trying to increase a market share. We're modernizing the OS we prefer to use. Earlier you asked: Why convert 98 into an OS we already have? Instead of doing all that, why not just use Win 2K? I can't speak for everyone here, but one reason many of us use 98 is that we don't want to use an NT kernel or a service based operating system. IMO, we'll do better making 98 into the OS it could have become, not converting it into something we already have. 98 has become much more capable and stable than it ever has been and is still getting better. I couldn't agree more. The point 9x/ME becomes an NT-family OS is the point I'd dump it for XP, which I already also use. The main attractive of 9x/ME is that its *NOT* an NT-family OS. My 2 ¢, of course.

My 2 ¢: Patch the KernelEx stub. Solves all problems, the source is available so it's easy to create a good patch, doesn't involve recompiling the original KernelEx and doesn't touch any system files. This should be the safest possible strategy, IMHO.

Well, it has no 64-bit support, and lacks a lot of bells and whistles, but let's not forget IDA Freeware. It's now difficult to get to it in the Hex-Rays page, but it remains in existence. This post is for the benefit of anyone who comes to this thread and gets interested by the above post, then discouraged by IDA's prices. While I do agree that the future lies in 64-bits, I reckon there's still much to be done in 32-bit yet, as of now. ...and ther is the IDA Palace, of course.

And if you are on XP, you actually don't need to. Download ChipGenius run it, and it'll tell you all you ever wanted to know about the pendrive and more!

IIRR, WDMSTUB is set to to load automatically with USBSTOR. If that's correct, WDMSTUB will be present only when some USB Mass Storage Device is connected, because those WDM drivers are loaded (and unloaded) dynamically. By modifying also USBCDC.INF we cater for the case when one USB serial device is connected, but no USB Mass Storage Device is also connected. When both are connected Windows takes care to prevent the double loading, if I'm not mistaken. That should keep us on the safe side.

gerislamico may well be right... and in case he is, I cannot resist telling you: "I said so!" Well, Drugwash, IMO what blorked your system was the .inf inside USB20DRV. Of course the files it contains are OK for your system, provided USBSTOR.INF is edited to load WDMSTUB.SYS with USBSTOR.SYS. Now, adding the untested (AFAIK) USBSER.SYS from XP SP3 didn't help any, either. Fact is, I tested it with WDMCHECK.EXE, and it turns out to have the same 3 unsatisfied dependencies that the USBSTOR.SYS (v. 5.0.2195.6773) from USB20DRV has. On the bright side it means it should work, provided it's also loaded with WDMSTUB.SYS, and this means finding the .inf that sets its registry entry and editing it too. The downside is it may be more than one .inf... USBSER.SYS is for the USB virtual serial port, which is mostly used to support USB modems, AFAIK. Here's a screenshot of WDMCHECK's output: I *think* the relevant file is USBCDC.INF, which must be edited in 3 places...

So... we should use the original, unmodified, bitmap for 161, right?

Whitney Houston - I'll always love you She passed away yesterday at 48. May she RIP.

In some contexts subverting is much more handy than disabling... If a way is found to log in as the TrustedInstaller, or to become it (just as one can become the SYSTEM user in XP), that would be a huge step in the right direction, IMHO.

Well, I have no experience whatever with x64 code but the link you provided about PatchGuard shows it really is complex. However, I have sufficient experience with patching x86 code to agree that it would be better to patch the x86 code below the 2-byte NOP, to avoid surprises. But, as far as making the entry-point return 0, on x86 at least, it's a good bet. The least the patch the better chance it has of working right. Of course, here the idea of making things simple enough, but not any simpler, fits like a glove.

I think fdv was referrring to Win 7 x86, since that's the OS displayed in his profile. And your finding it in the 32-bit version in SysWOW64 tends to confirm it. The byte pattern in x64 should be different, and probably use 64-bit registers instead.

Now, that's an interesting project! I'd give it a shot myself, but I've got no machine using Win 7 ATM, although I've bought Win 7 and intend it to be one of the OSes of my next machine (which ATM is just a bunch of parts which assembly I can still assign no ETA, unfortunately). Just a heads up: modifype.exe is not a good idea anymore, since it refuses to work right under Vista and 7. n7Epsilon's PEChecksum.exe should be used instead, in all cases.

I sure do.