jds

Maybe "Safe Mode with Networking" and uploading to an FTP server app running on another machine? Or ... save another Ghost image and extract those files later from the Ghost image once you're operational again. Or ... use DOS and USB drivers (and the 'doslfn' TSR if necessary) to save to your Flash drive. Joe.

I don't know first hand, however, reading the following suggests the above is misinformation : http://www.danbricklin.com/history/vcexecutable.htm Joe.

Well, I can confirm method 4 works! I can now use the unpatched version of 'JPlatin.dll' in the SAP GUI for Java client. Joe. PS. Altium Viewer 6.3 is also working with an unpatched 'DXP.exe'.

fwd doesn't yet support the renaming of external functions. Adding the functions in ipstub to netapi32 won't work because the new functions will not have the names we need. No, that's not the problem. I took care of the renaming issue by also patching the 'JPlatin.dll' file with Import Patcher. Dependency Walker was satisfied with the end result, but it didn't work. Joe.

Not true! Back in the day, I had a very memory-demanding application, whose needs could only be met in "raw DOS" as you call it, not in Windows. What you say may apply only if you compare to an un-optimized DOS system, or perhaps one optimized with the 'MemMaker' utility. However if you are skilled, it is possible to achieve up to 120K more available memory than what 'MemMaker' can achieve. With DR-DOS, even more is possible, for example, I had a CD-ROM driver, mouse driver, LAN card driver and the bloated MS network client drivers [edit: and a disk cache] all loaded, and still almost 640K of available conventional memory. Joe.

Careful not to "stress" the olde 82371SB, it will break. See : http://www.usbman.com/Guides/known_issues.htm Joe.

Well, they should. But so far there have been no reports of success. IPstub.dll did not have the checksum set, so modding the file goes undetected. fwd.03 is now posted--it updates the Link Checksum after all forwarders are added. It will also correct the Link Checksum for any PE file! See post #1 for details. Yeah, something must be wrong. I finally managed to get SAP GUI for Java to work by stubbing both 'netapi32.dll' functions, instead of using 'fwd' : Joe.

Installing "SAP GUI for Java (Win32) 7.10r5" on W98/KernelEx : Here is a very brief description of the special steps needed to install "SAP GUI for Java (Win32) 7.10r5" on W98/KernelEx, with the help of "Import Patcher" and 'IPStub.dll' ... 0) Prerequisites Well, these are the official prerequisites : The other prerequisite is a copy of the "SAP GUI for Java" (Win32 version) installation package, once readily available via FTP from SAP, now you need to register and navigate their convoluted web site to get it. The version used here was 'PlatinGUI-Win32-710r5.jar', however, only the most current version is generally available from SAP, which may or may not work as below. Note that version 7.10 is the minimum required to access current SAP systems. 1) Create directory structures on your W98 partition C:\Users C:\Users\YourUserName C:\Users\YourUserName\Local C:\Users\YourUserName\Local\Temp C:\Users\YourUserName\Roaming C:\WINDOWS\SAP Clients C:\WINDOWS\SAPGUI C:\WINDOWS\SAPGUI\work 2) Add "Volatile-Environment" Registry Entries ---snip--- REGEDIT4 [HKEY_CURRENT_USER\Volatile Environment] "LOGONSERVER"="\\\\SERVERNAME" "USERDNSDOMAIN"="Your.Domain.Suffix" "USERDOMAIN"="YOURDOMAIN" "USERNAME"="YourUserName" "USERPROFILE"="C:\\Users\\YourUserName" "HOMEPATH"="\\Users\\YourUserName" "HOMEDRIVE"="C:" "APPDATA"="C:\\Users\\YourUserName\\AppData\\Roaming" "LOCALAPPDATA"="C:\\Users\\YourUserName\\AppData\\Local" ---snip--- 3) Obtain REG.EXE Extract with 7-Zip from 'sp4supporttools.exe' from : http://www.microsoft.com/download/en/confirmation.aspx?id=18614 Copy to %windir% 4) Obtain CMD.EXE WIN95CMD.EXE (originally from October 2000 Platform SDK) : http://web.archive.org/web/20040603061357/http://www.neuro.gatech.edu/users/cwilson/cygutils/unversioned/consize/Win95Cmd.exe Possible alternative is CMD.EXE from ReactOS 0.3.1 or earlier. Copy to %windir% 5) Pipe Work-around for WIN95CMD.EXE (Charles Dye) ---snip--- REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor] "AutoRun"="set comspec=C:\\windows\\cmd.exe" "CompletionChar"=dword:00000009 ---snip--- 6) Update in %windir%\SYSTEM : IMAGEHLP.DLL 5.1.2600.2180 (Readily available) dbghelp.dll 6.0.0017.0 (Available in 'WinAVR' or 'RealPlayer') 7) Install the JAR package 8) Patch 'JPlatin.dll' with "Import Patcher" & 'IPStub.dll' ---snip--- [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 [KERNEL32.dll] OpenThread= [ADVAPI32.dll] ConvertStringSecurityDescriptorToSecurityDescriptorA= [iPStub.dll] NetUserEnum=o8 Netbios=f1 [Patch list] JPlatin.dll=DLLs, Functions ---snip--- 9) Here's the batch file to invoke SAP GUI : ---snip--- javaw.exe -Xmx256M -cp "C:\PROGRA~1\SAP Clients\SAPGUI for Java 7.10rev5\jar\GuiStartS.jar";"C:\PROGRA~1\SAP Clients\SAPGUI for Java 7.10rev5\jar\platincoreS.jar" %PLATIN_JVMOPT% com.sap.platin.Gui %1 %2 %3 %4 %5 %6 %7 %8 %9 ---snip--- Phew! Well, that's pretty much it! Joe.

Well, I deleted RP due to its messing up my quick launch / task bar. So I can't say about the coloured lights, however, see below ... Well, I'd not heard of Mcafee "Nuts & Bolts" nor "WinGauge" before, however, I've managed to track down an evaluation copy at some academic/teaching site : http://www.cbe.name/share.srf/tppmsgs/share.srf?changefolder=1&folder=%5C(03%BF%CE%BC%FE%CB%D8%B2%C4)%5C%B9%B2%CF%ED%C8%ED%BC%FE%5C%B9%B2%CF%ED%C8%ED%BC%FE%BF%E22%5C162This file seems to have originally been available here (defunct URL) : http://download.mcafee.com/products/evaluation/nuts_and_bolts/english/win9x/NB0201AD.EXE Anyway, after figuring out how to use "WinGauge" (wgpro32.exe), I'm impressed by the range of parameters it can monitor or report. Your assertion that the 16-bit GDI and User resources are most critical seems to be true. As I write this, the 16-bit versions are showing about 40% usage, whereas the 32-bit versions are showing less than 10% usage. However, resource leakage hasn't occurred (much) yet, so that situation may change. Also, GDT shows 1% usage and LDT shows 37% usage. Joe.

No, the "World's most useless Microsoft operating system of all time" was what ran on the Hitachi Peach, an amalgam of machine language and BASIC. This thing ran so slowly that to duplicate a floppy disk (I can't remember the capacity, probably 1XX KB) took one hour, about 20m to format the new floppy, 20m to copy the tracks, and another 20m to verify. No joke, that's really how long it took! BTW, I entirely agree with your views on MSW3.X, its only use was to run IE 3.02a on old hardware (best 'net performance I've encountered, although useless today). Yeah, rename 'win.com' to 'gui.com' (and call it in 'autoexec.bat' if you wish), and "shutdown" will bring you back to DOS instead of shutting down. Joe.

Well, there is a problem... While I used 16M for both GDIMaxHeapSize and USERMaxHeapSize, I had this issue, which went away when I fell back to 4096. However, since RP calls the Windows native LDT cleanup when LDT is lower than 20%, you won't normally notice that issue, except for the red light. But it's much better to avoid having the LDT cleanup routine (which Tihiy deems not that effective anyway) called more sparingly, to avoid unnecessary system processing, so 4M is the best value to use for both. A Suffusion of Red? Thanks for those numbers, Den. I've been using GDIMaxHeapSize=8192 on all my W98SE machines for some months now, to good effect. As for USERMaxHeapSize, I've not been able to set this anyway, from what I've read, this is a string variable in "HKCU\Control Panel\Desktop", yet there seems no effect whatever value is used for it. Joe.

Well, you could include the Microsoft driver that I customized and the 'wmdmcmd.exe' utility, this is sufficient for rudimentary support of standard PTP/MTP devices and is fairly small (and it works and it doesn't break TWAIN drivers). Joe.

I don't know what works with XP, I don't use it. This WIA package is supposed to work for 98, but I haven't figured out when/how. Joe.

mikroPascal PRO for ARM 2.00, from www.mikroe.com (with KernelEx 4.5.2). After installing the compiler (I chose not to install the optional mikroProg suite and drivers, so I don't know their compatibility), it is necessary to replace the installed 'FTD2XX.dll' file (yeah, that's an interface to FTDI's USB driver; even if you elect not to install the drivers, there's still a dependency on this DLL by the compiler application) with a W98 compatible version from here. Then simply run the compiler in default compatibility mode or some W9X compatibility mode. If you chose an NT compatibility mode, instant crash! BTW, there's a minor nuisance crash (access violation) on exit, but it doesn't seem to affect anything. This is about the newest compiler at this time from MikroElektronika, so the others there are probably also compatible in the same manner, perhaps even more so. Joe.

The iPod Touch / iPhone utility/driver that gives you some mass storage capability on your device, does so by creating a separate partition or virtual drive or some such, which may be handy if you don't want to carry a Flash stick around, but useless for accessing your media files on the device. As for those PC drivers that claim to provide mass-storage access to the media files on your iPod, they are just a conventional USB mass storage driver (actually, a customized example driver originally from MS), and only work on older iPod devices prior to the PTP/MTP(?) models. Basically, Apple tried to lock up your media files with proprietary databases on their iPods and force you to use iTunes, but when these were reverse-engineered and you had alternatives, they then eliminated mass-storage mode and came up with what is probably a proprietary version of PTP/MTP. Joe.

I think you get the (inf) file from a WinXP machine. I not sure because it wasn't present on any of my comps. OK, I managed to find a copy of PTPUSB.INF (version 5.1.2600.0) at www.infdump.com, and tried this with the requisite DLL's from the WIA package. Well, I added my Fujifilm camera's USB ID, etc. to the INF file, so basically this invoked the same 'PTP' section as for the "Generic" case. The driver installed fine, asking for the location of a DLL or two, after which the camera appeared in the Device Manager as an Imaging Device, and reported as "working properly". It also showed up in 'Scanners & Cameras'. However, that's as far as it got. It wasn't available via the Imaging application, nor IrfanView, nor more importantly, WIA's "Scanner and Camera Wizard". So again, WIA seems useless. PTPUSB.INF also seems useless. The only thing that's worked is the supplied Fujifilm driver with their cumbersome FinePix Viewer and Microsoft's driver that I customized here and here with their 'wmdmcmd.exe' utility. Joe.

OK, the WIA package includes version 4.90.3000.1 of the DLL's, however, where do I find that INF file? Joe.

Yes, that's pretty much what happens for me too, however, the camera fails to be recognized by the WIA "Scanner and Camera Wizard" (in Start/Programs/Accessories). So in effect, the WIA stuff does nothing, we are forced to use the supplied viewer software, which is bloated and cumbersome, especially when you start to fill your memory card. As for the "add device" feature under "Scanners and Cameras", this only seems to select from devices in "stillcam.inf", so my camera model isn't selectable that way, even though its driver is available via the standard "add new hardware" wizard. Joe.

Thanks Can't wait to see to the results. Well, I've tried to make this stuff work over the past couple of days, with the following results : Firstly, Fredledingue is right. After installing WIA, "HP Scanjet Scanners" (links to 'HPSCNMGR.DLL') no longer appeared in the Control Panel. The 'HPSCNMGR.DLL' file was newer and the 'STICPL.CPL' file was missing. The HP scanner still showed in Device Manager and was supposedly working properly, however, it was neither recognized as present by the HP software nor the WIA "Scanner and Camera Wizard" (links to '%windir%\SYSTEM\WIAACMGR.EXE -SelectDevice'). Restoring the 'HPSCNMGR.DLL' and 'STICPL.CPL' files made no apparent difference. As for the Fujifilm camera ... - Using the Microsoft PTP/MTP drivers, as customized in the INF file I uploaded elsewhere, I could only get it to work with the Microsoft 'wmdmcmd.exe' tool, not the Fujifilm software, nor the WIA "Scanner and Camera Wizard", neither was it listed under "Scanners and Cameras" in the Control Panel. - Conversely, the supplied Fujifilm driver did not work with the Microsoft 'wmdmcmd.exe' tool, but did work with the Fujifilm software and was listed under "Scanners and Cameras" in the Control Panel. However, this too failed to be recognized by the WIA "Scanner and Camera Wizard". When I deleted the HP scanner from Device Manager and rebooted, it was re-installed as a WIA device and was listed under "Scanners and Cameras" in the Control Panel, however, it failed to be recognized by the WIA "Scanner and Camera Wizard". After deleting the HP scanner again from Device Manager and also the associated INF file installed by the WIA (I forgot to note its name), I was finally able to restore operation by re-installing the original HP software (a difficult task involving three different version of software and various work-arounds, which is why I hesitated to do this experiment). So I can confirm that this WIA stuff can break your TWAIN scanner installation. As for getting it do do anything useful, unfortunately, I was only able to get the two devices listed under "Scanners and Cameras" in the Control Panel, yet somehow, not recognized by the WIA "Scanner and Camera Wizard". I also found that the Microsoft PTP/MTP driver wasn't recognized at all (for the Fujifilm camera), yet only this worked with the Microsoft 'wmdmcmd.exe' tool. Joe.

Theoretically, yes. But don't forget that DLLs patched by fwd don't actually work yet. However, if "my.dll" really is yours that you built from source, you can export forward to "big.dll" in the link step and don't needed fwd. That is the method unrelated to fwd that actually works. Sorry to still be confused, I thought "small" DLL's patched by 'fwd' did work? That's why I asked if 'IPStub.dll' was a suitable "small" DLL. If my understanding was incorrect, and patching either way with 'fwd' is non-functional, that could explain why my Java SAP Client experiment was a failure. BTW, the checksum error in "Dependency Walker" did not occur when I used 'IPStub.dll' as the base DLL, with forwarding to 'netapi32.dll'. Joe.

Theoretically, yes. But don't forget that DLLs patched by fwd don't actually work yet. However, if "my.dll" really is yours that you built from source, you can export forward to "big.dll" in the link step and don't needed fwd. That is the method unrelated to fwd that actually works. Sorry to still be confused, I thought "small" DLL's patched by 'fwd' did work? That's why I asked if 'IPStub.dll' was a suitable "small" DLL. If my understanding was incorrect, and patching either way with 'fwd' is non-functional, that could explain why my Java SAP Client experiment was a failure. BTW, the checksum error in "Dependency Walker" did not occur when I used 'IPStub.dll' as the base DLL, with forwarding to 'netapi32.dll'. Joe.

No. "reverse the direction" refers to another method unrelated to fwd. But ... but ... you said "I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL". Now, if I use command "fwd big.dll my.dll" (as per the first post currently), I will get a "big.dll" which forwards to "my.dll". So if instead "my.dll" is to forward to "big.dll", then the command needs to be reversed as "fwd my.dll big.dll", right? An interesting thing also happened when I tried command "fwd.01.exe netapi32.dll ipstub.dll". The resultant 'netapi32.dll' showed a "Link Checksum" discrepancy in Dependecy Walker. Same thing happens with 'fwd.02.exe'. Joe.

Q1: Does this mean the instructions in the first post need to be revised? eg. "Usage: fwd big.dll my.dll" becomes "Usage: fwd my.dll big.dll"? Q2: Is 'IPStub.dll' suitable as the "small DLL"? BTW, I haven't had any luck getting "SAPGUI for Java 7.10rev5" working. I used 'fwd' to make a special version of 'IPStub.dll' (called 'netapi33.dll') which forwarded the 'Netbios' function to 'netapi32.dll' and provided the usual dummy stub functions. Then I used "Import Patcher" to substitute 'netapi33.dll' for 'netapi32.dll' and the 'o8' function for 'NetUserEnum'. It looked OK in "Dependency Walker", however gave the same "JniAgiLibAdaptor.<init>: Cannot load JNI library" error for 'JPlatin.dll' as before. Joe.

Well, that's encouraging. It would be nice if Fredledingue could give more details and perhaps try restoring the 'STICPL.CPL' file to see if that restored TWAIN functionality. Anyway, I've decided to give this a try too ... after first making a backup image of my partition. 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. Well, I have progress to report, of sorts. In investigating this error, I encountered some test results at WineHQ with different versions of Altium Viewer (albeit with different versions of Wine). This suggested that versions up to 6.8 were well behaved, whereas the more recent versions, weren't. So I did a search of some backups and found a copy of version 6.3.0.6886 and installed this, as described earlier (the MSI LaunchCondition was a bit different, but fairly obvious). It works! However there's a catch. Previous versions of Altium Viewer require a registration key and activation. Unfortunately, the system Altium have for generating such registration keys no longer works for version 6, so I had to get help from Altium Support to get a suitable registration key generated. Then it all worked! Unfortunately, Viewer 6 is no longer supported by Altium, so unless you're a good customer, they won't normally be willing to manually generate a registration key for it. However, this does show that Altium Viewer is viable on W98, version 6.3 works, and more recent versions perhaps just require one or two API functions to be fixed up for them to work too. I can't agree more. I did such research before selecting the two IPStub functions to use with Altium Viewer, there's enough that can go wrong to trust trial and error. Joe.