jds

Thank you! {Edit: Deleted silly question ... I need my eyes checked ...} Joe.

After reading heres my take on everything. The Picture Transfer Protocol (PTP) drivers is a part of Windows Image Acquisition (WIA). Microsoft said so themselves. I don't think anyone can run Picture Transfer Protocol (PTP) without using Windows Image Acquisition (WIA) at least on Win98. Not really true. I have successfully used the 'wmdmcmd' tool instead of WIA. Thats because TWAIN and WIA don't mix, wise words from Microsoft. Reason why (WIA) deletes STICPL.CPL because its apart of TWAIN and WIA doesn't use it. Am I cynical, or does that seem like sabotage? Anyway, if Fredledingue is able to restore TWAIN operation by restoring STICPL.CPL, then I can also try this WIA stuff. New, newer, newest. Unfortunately, MS seems to have persuaded many camera manufacturers to switch from Mass Storage to PTP/MTP in their newest offerings. Probably for DRM purposes (yeah, stupid mentality, how is DRM relevant to pictures I take with my own camera, huh?).Joe.

Well, there's no disk geometry misconfiguration, as the 15079 errors occurred randomly during each attempt at saving a partition image. In other words, different files were flagged as having a smaller size than reported, each time an attempt was made. Also, the drive tested fine with every test utility I could find and performed/behaved perfectly normally. Anyway, I've now substituted a slightly larger drive for the WDC, in the same secondary master position. It doesn't exhibit any 15079 errors, random or otherwise. So it seems this issue was some obscure compatibility issue between Ghost and this particular drive. So if you ever encounter similar random "15079 (size less than reported)" errors, and you don't find any problems with the drive, the solution is the "-FNI" command line switch. Joe.

AFAIK, MTP is a super-set of PTP (well, at least, it supersedes it and I believe it is backward-compatible with PTP devices). One issue though - Fredledingue says his other TWAIN devices disappeared after installing WIA. If that's the case, I won't risk installing WIA, as it was extremely difficult getting my TWAIN stuff from HP to work in the first place! Joe.

WIA is controlled by MS. Thanks, I have renamed your PTP_MTP.INF to MTPPTP.INF. I'd still like to know what 'mtpsmgr.exe' does and how to use it ... Anyway, I retested 'wpdusb.sys' (5.2.3810.3924) with the iPod Touch and, with or without 'wdmstub', it didn't work, so please supply the 9X version, not this one. BTW, I mentioned earlier that the iTouch was mostly non-functional. I'm sure Apple have modified PTP/MTP to require iTunes. Anyway, the main use for this driver with the iTouch is to enable it to be charged, as otherwise it will just sit there connected to a W98SE machine and just ignore the 5V it's receiving. If anybody can get more useful functionality, let us know. Joe.

I don't think I'm going to add any tools, just system drivers. OK, but are there any suitable applications so those tools won't be required? If not, then the drivers themselves won't be useful for the normal user. I think we should have one inf file for all the drivers, named something like (MTPPTP.INF) combining the two you posted above. After using it as a starting point, we can just add new devices. Good idea. Attached. Joe. PTP_MTP.INF

Great idea. I experimented with this stuff a while ago, see : EDIT : Updated above URL = https://msfn.org/board/topic/105936-last-versions-of-software-for-windows-98se/page/40/#comment-967232 Now, a few things to note ... I wasn't able to figure out how to use 'MTPSMGR.EXE' or indeed, what it does. Any clues on this one? Also, there exists a version 2.0.0.7 of 'WMDMCMD.EXE', in a huge package called 'p4sdevicekit.exe'. I've no idea what's changed. Here's the list of application-level stuff that I found useful for MTP/PTP : WMDMDEVS.exe WMDMCMD.exe MtpLib.dll MtpMon.exe readme_wmdmcmd.txt Finally, I notice that 'wdmcheck' has nothing to report about 'WPDUSB.SYS' version 5.2.3810.3924, so do you know if 'wdmstub' really makes any difference with it (I only ever tried 'WPDUSB9X.SYS')? Joe. PS. Attached are INF files I prepared for a Fujifilm digital camera and and iPod Touch. The camera worked, but the iTouch mostly didn't (thanks a lot, Apple!). FujiFilm.inf iTouch.inf

Firstly you have to disable the broken COM1 port, probably in BIOS, perhaps in Device Manager. Secondly you have to reconfigure your USB Virtual COM port; there is probably an option in Device Manager provided by your device driver. If not, get a different brand of USB converter (for instance, if it's an FTDI device, this option is in the "Advanced" settings). Joe.

I recently encountered an issue with Ghost 8.3, may also affect Ghost 2003 (since this is older) : I was trying to save a partition image from a WDC WD64AA version 82.10A82 hard drive, and was getting random "15079 (size less than reported)" errors. Searching for solutions on the 'net all said to run 'scandisk' or similar tools to correct for disk corruptions. However, all tools I could find, reported nothing wrong with the disk data structure. By trial and error, I found the solution was to use the "-FNI" command line option, which disables Direct IDE Access by Ghost. BTW, the target drive to save the image was a USB drive. Also, the other hard drives on the same machine did not exhibit this random 15079 error when backing up their partitions, just the WDC drive. [Edit: I also should mention, in case it's relevant, the WDC drive was on the secondary IDE port, whereas the other drives were on the primary IDE port.] Joe.

Well, this thread sort of got sidetracked over another 2G issue and the support for different seek modes in patched versions of 'kernel32.dll', which is progress nonetheless, however, the original issue (2G limitations for 16 bit app's and MS-DOS 7.10 itself) is yet unresolved. Is this an "IO.SYS" problem and would it be possible to fix? Joe.

Hey, that's great news! I'll keep in mind to try augmenting a small DLL when it comes time to try this out (at least until you've resolved the issues with the more complex DLL's). I'm considering if this tool might help me get "SAPGUI for Java 7.10rev5" working ... B) Joe.

Yeah, so close and yet ... I get the impression that NT has more internal traps for errors that are silently dealt with than does W9X. So coding errors (hey, even compiler errors!) go unnoticed. Maybe that's it, or maybe there are a few holes or bugs in what KernelEx is providing, I don't really know. Joe.

Next experiment ... Well, I've just tried to apply "ImportPatcher.34" with "IPStub.dll" to the Altium Designer Viewer : http://downloads.altium.com/altiumdesigner/AltiumDesignerViewerBuild9.3.0.19153.zip After downloading and extracting the ZIP file, it is necessary to edit 'Setup\Setup.msi' in Orca and delete the "NOT Version9X" row in "LaunchCondition", then "Save" it (avoid using "Save As"). Running 'Setup.exe' stalls during the "Deleting backup files" phase. However, running it again and selecting "Repair" is successful. Now that Altium Viewer is installed, it is necessary to patch 'dxp.exe' for two dependencies from 'Netapi32.dll'. Since nothing else is used from the W9X version of 'Netapi32.dll', we substitute the DLL with 'IPStub.dll' and select the 'o1' and 'o3' functions, per the following 'dx#.ini' file : [ImportPatcher.34] ;Edit parameters and replacement strings, then Retry or run again to patch. <= [Parameters] Walk dependencies=N Link to copies=N Unbind broken bindings=N Target OS=4.10 [DLL substitutions] Netapi32.dll=IPStub.dll [user32.dll] UpdateLayeredWindow= [IPStub.dll] NetApiBufferFree=o1 NetWkstaGetInfo=o3 [Patch list] dxp.exe=DLLs, Functions [Need patching? (do not edit)] C:\Program Files\Altium Designer S09 Viewer\dxp.exe=Y (function name) So far, so good. With the additional assistance of KernelEx 4.5.2 (default setting is fine), we are able to launch Altium Viewer. Unfortunately however, for me, it crashes : Substituting the 'IPStub.dll' debugging functions for 'Netapi32.dll' (instead of 'o1' and 'o3') did not produce any pop-ups, so the crash occurs before either of the substituted functions is called. In other words, the import patching doesn't seem responsible for the crash. So ... Is some KernelEx code failing? If this software works on XP or whatever, and all its required functions (AFAIK) are being supplied on W98, why should it crash in this way? Any ideas? Joe.

Hi jumper, Does this mean 'fwd' can't work (yet)? : Joe.

Kerio 2 is W98 compatible, so if KernelEx causes problems with PFWADMIN.EXE, you should try setting the compatibility mode to "disabled" (and report back). As for drivers, tweaking KernelEx isn't going to help, it's for applications only, not drivers. If you do have driver issues, such as non-support of W98, have a look at the WdmStub thread. OTOH, if you have misbehaving W98 drivers due to excessive speed, there's not much you can do unless you are able to debug and patch them. Joe.

Thanks for the explanations, guys. So it's not just with KernelEx that you can't depend on Dependency Walker OK, so we don't actually need those XP files, and it sounds like the nusb30e build of WdmStub is the default one to try. Any idea if its source exists somewhere? Also, a crazy idea occurred to me ... if the above XP files don't have dependencies other than between themselves, could they be used together as an alternative to WdmStub (ignoring for the moment the problem that you'd probably need a license for XP to use them legitimately, which not all W98 users would have)? Joe.

Well, if it involves using WdmStub, then it may be better to post in the WdmStub thread, to make it easier to find later (rather than a separate thread). Joe.

Wow! 2012 really is the year of code! This sounds like just what the doctor ordered ... time to dig out those applications where KernelEx wasn't quite enough. Great work, jumper. Joe.

I have been wondering about the three different versions 5.00.006 of WDMSTUB.SYS (that we know of, so far), and what may be different between them. Anyway, when I opened them with Dependency Walker, it reported the following dependencies : Oneysoft version => ntoskrnl.exe, HAL.DLL Garmin version => ntoskrnl.exe NUSB30e version => ntoskrnl.exe Digging deeper with Dependency Walker revealed these dependencies : ntoskrnl.exe => bootvid.dll, HAL.DLL, kdcom.dll HAL.DLL => ntoskrnl.exe bootvid.dll => ntoskrnl.exe, HAL.DLL kdcom.dll => ntoskrnl.exe, HAL.DLL So, all three versions ultimately show the same dependencies, but only the Oneysoft version shows a direct dependency on HAL.DLL (and is also noticeably larger than the other two, more recent, versions). I'm not sure, but that suggests to me that there may be functional differences between these three versions, despite the identical version numbering. The other notable thing, is that these apparent dependencies are not provided by W98SE. I searched around to find these versions of said files, before Dependency Walker was fully satisfied with WDMSTUB.SYS : bootvid.dll = 5.1.2600.0 (xpclient.010817-1148) HAL.DLL = 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) kdcom.dll = 5.1.2600.0 (xpclient.010817-1148) ntoskrnl.exe = 5.1.2600.2622 (xpsp_sp2_gdr.050301-1519) Now I wonder, are these extra modules sometimes needed for WdmStub to do its job on W98, or are they only used on say, W2000? Joe.

Why don't you want to update ESDI_506.PDR? Your HDD exceeds 128G, so you need LBA48 support, which if I recall correctly, means you need a patched ESDI_506.PDR. Also, be sure your BIOS supports LBA48, else you may have some disaster in your future. BTW, NDD crashes when it has too many files, long before you fill a typical 128G partition. Delete 'scandisk.alt' to revert to the standard scandisk. Joe.

Thanks, PROBLEMCHYLD, you've done well! This gives us the green light! BTW, can you also give us the time/date of the e-mail? Probably not important, but it helps with traceability. In case you haven't seen it, below is the notice that comes with the WdmStub code. So you can see why it was important to get more up-to-date permission for what we're wanting to do here : Joe.

No because he contacted me by email. Its personal and I will not share my emails on the internet. (You are more than welcome to hack it though).I have better things to do then to lie about what people have sent me via email. If my word is not Good, then all I do is a lie. And I'm not a liar. And besides, how would I know the source code is offered with the book if I don't own it. Eh? Nobody is calling you a liar. Why would you think that??? It's simply a legal formality. The published license for WdmStub specifically says it cannot be redistributed except by explicit permission of Walter Oney. That's where we stand legally, unless we can prove otherwise, eg. to the people running MSFN. Only the relevant portions of the e-mail, plus the time/date information, should suffice. As for the source code, you can either get it on the CD-ROM if you buy the book, or you can download it as described in the first posting. Of course, the benefit in buying the book is that all the stuff is explained, otherwise you have to figure it out yourself. Joe.

If you download and update per the first posting, you will also have the source code. Interesting. This is quite different to his published advice on these matters. Yet, if we can modify and distribute under a new name, that will do for our needs! Are you able to post (quote) the relevant text from Walter? Joe.

Version 5.0.0.4 is also what you get it you download the Walter Oney CD-ROM contents and don't apply the update (I can't say if it's exactly the same as your SoundMax one, since my AD1885 driver doesn't have this). 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. I don't know too much about 'update.sys', but it's listed under the Processor section of Device Manager, so you may be right about it only applying to Intel processors. I chose to nominate 'usbd.sys' because the most common situation for loading redundant copies of WdmStub are probably, as you've described, due to removable USB devices. So I figured that this one, associated with the USB host controller, would be appropriate. So the questions, for those with appropriate hardware, are : 1. Does 'usbd.sys' also get used if you have an OHCI or EHCI controller (mine's UHCI)? 2. If you have multiple USB controllers, does each have a separate instance of 'usbd.sys'? 3. If you have an AMD-based machine, does it also use 'usbd.sys' as part of the USB stack? Joe.

Now I understand. How about??? : HKR,,NTMPDriver,,"wdmstub.sys,usbd.sys" Joe.