jumper

This sounds like a project wish to me: My experience with FAT32 is that apps escape any characters that would be illegal: %3F %2A %2F .... Would hooking the system file APIs to un/escape name strings work? Would unicode file names be a problem (or a solution)? What about path length limits? The problems I run into here usually concern command-line parameter passing to (my) apps or DOS batch files.

MSVCRT.DLL version 6.10.9848.0 contains _fstat64. So also do MSVCR70.DLL 7.00.9981.0 and MSVCR71.DLL 7.10.7031.4 (for anyone using them as a MSVCRT.DLL update). All are available in 98 SE SP 3.0.

Is the activity light on the pen drive on during the delay? Something is probably writing to the drive, causing the delay. A faster pen drive should have less delay. ResourceMeter can show you how much (and how fast) data is being written to the drive. Use a process viewer to determine what program is most active during the delay. If it is a virus scanner, disable scanning on that drive letter. You may also be able to enable (or disable) caching of removable drives to improve performance: ->Control Panel->System->Performance->File System->Removable Disk

After two months of delays , ImportPatcher.35 is finally posted. I added CheckSum zeroing so Dependency Walker would stop complaining about the invalid checksums.

Two better versions to try: ComDlgEx.7z ComDlgEx.dll - supports all three new functions: PrintDlgExA - uses PRINTDLGA struct to call PrintDlgA PrintDlgExW - uses PRINTDLGW struct to call PrintDlgW Ssync_ANSI_UNICODE_Struct_For_WOW - stub: SetLastError(ERROR_CALL_NOT_IMPLEMENTED) [*]ComDlgEx2.dll - as before, but support for both flavors PrintDlgExA - uses PRINTDLGA struct to call PrintDlgA PrintDlgExW - redirects to PrintDlgExA Recommended installation method: 1b.

If win.com runs from autoexec.bat, try adding: win.com @cd\ @dir /b/w > nul @cd\windows or create a win.bat with the above code. For automated windows exit and restart, perhaps you could put reboot.exe in the root directory and have windows run it from there.

A Google search for "SeaMonkey +PrintDlgW" yields antivirus scans showing that SeaMonkey 1.9 and 5.0 use PrintDlgW. And Firefox 9.0 too! Method 2 seems to cause Kex to bypass its internal ComDlg32 support. Methods 1 and 3 should be complementary to Kex--use one of them with the current ComDlg32 update to prevent apps that need PrintDlgExW from failing to load. This is excellent feedback. It made me realize that if I add a stub for PrintDlgExW that returns success instead of failure (as Kex does), the default parameters will be used unchanged and something might print for those apps (like SumatraPDF 1.9) that need PrintDlgExW!

This update currently only addresses the missing PrintDlgExA function in ComDlg32.dll. Try testing with SumatraPDF 0.9 instead. With Seamonkey loaded, try deleting <system>\ComDlg00.dll. If you get a file-in-use error, that will confirm that the new ComDlg32.dll is correctly installed and in use. Does Seamonkey display a Print Dialog at all? If not, Seamonkey must not be calling PrintDlgExA and has another issue not addressed by this update. Please search the Seamonkey folder for files with text "PrintDlgExA". If none are found, Seamonkey cannot be used to test this update. Instead, use ImportPatcher to test Seamonkey for missing imports and post results here. Thanks! Tonight I will try to implement PrintDlgExW and update the update.

Three ways to install the ComDlg32.dll update: In <system> folder (affects all applications including OS): rename to ComDlgEx.dll and place in <system> folder do one of the following: DOS method exit to DOS and cd to <system> folder rename COMDLG32.DLL to COMDLG00.DLL rename COMDLGEX.DLL to COMDLG32.DLL KnownDLLs method: copy <system>\ComDlg32.dll to <system>\ComDlg00.dll merge into registry: REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "COMDLG32"="ComDlgEx.DLL" In <windows>\KernelEx folder (affects only KernelEx-enabled applications): place in <windows>\KernelEx folder copy <system>\ComDlg32.dll to <system>\ComDlg00.dll merge into registry: REGEDIT4 [HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs] "COMDLG32"="ComDlg32.dll" In specific application/DLL folders (affects only those EXEs/DLLs): place in folder of EXE or DLL that references PrintDlgExA copy <system>\ComDlg32.dll to <system>\ComDlg00.dll remove any global redirection from registry: REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "COMDLG32"=- Note: To modify registry, save boxed text as new.reg, right-click and select 'Merge'; or use RegEdit.

If you also have a physical COM2 port, perhaps you can just swap them: In BIOS: swap COM1 and COM2 addresses and IRQ values In Windows: in System Properties->Device Manager->Resources unselect "Use automatic settings" for both COM1 and COM2 swap their Basic configurations. In Hardware: if you suspect a damaged connector, swap connector headers In DOS this might work: mode com1=com2

Installation clarification using SeaMonkey as an example: Q) Where in the SeaMonkey folder should I place the dll? I find dll's in almost every folder there. A) Place a copy of my ComDlg32.dll in the folder containing SeaMonkey.exe. Also, search for text "PrintDlgEx" in SeaMonkey's top folder using Find. Place a copy in the folder of each file that contains a reference to "PrintDlgEx". Q) Should I rename comdlg32.dll to comdlg00.dll and NOT replace the original windows one with your dll? So, Windows does not have this file at all? A) Copy (do not Rename) the original ComDlg32.dll: Right-click on the original ComDlg32.dll, drag until [+] appears and release, then select "Copy Here". Rename the new copy "ComDlg00.dll". The original ComDlg32.dll remains for all other programs to continue using.

ImportPatcher status update: IP.35 needed several rewrites before it became stable, but now the PE header parsing code is more robust than ever. It detects UPX-compressed files and doesn't attempt to parse the invalid delay-import entries. Three types of dependencies are still not supported: import forwarders, export forwarders, and dynamic delay-loads. I've been learning a lot about export forwarders lately and if import forwarders work the same way, both of these should be relatively simple to implement. Dependency Walker uses a profiling method to find dynamic delay-loads. A future IP could add a 'Profile' option to the summary MessageBox if there is a GetProcAddress dependency. If 'Profile' is selected, it would hook GetProcAddress and launch the app. Another possibility would be to search the code section for calls to GetProcAddress and grab the addresses of the function name strings. Search again for LoadLibrary and grab those DLL name strings, then cross reference functions and DLLs.

Boot Up Floppy Seek can be Disabled for a quieter boot. Memory Hole at 15M-16M can be Disabled. Auto Detect DIMM/PCI Clk should probably be Enabled for stability until you're ready to start tweaking. Spread Spectrum can be Enabled to reduce radio and television interference. The -5v supply is reading: -61.93v

Working solution: ComDlg32.7z Place ComDlg32.dll in app folder. In <winsysdir>, copy original COMDLG32.DLL to COMDLG00.DLL. Remove any COMDLG32 redirections in KnownDLLs. Should print to printer. Print to file not implemented yet in SumatraPDF 0.9. PrintDlgExA.c source:

Great job getting Altium Designer Viewer to install and launch. I see that you are leaving the user32.UpdateLayeredWindow replacement for KernelEx to handle: [user32.dll] UpdateLayeredWindow= KernelEx only provides full functionality for a few functions. Most of its support consists of error stubs and minimal functionality to address specific issues in this or that app in response to a direct request. There does appear to be a full implementation for UpdateLayeredWindow, however. Most apps (including mine ) don't check every last error code. When an app crashes, it generally means that something critical has already failed (before the actual crash) and the app isn't going to be able to proceed anyway. It could check return codes for errors and display a friendly failure message, or it can not check and then (possibly) crash. Ironically, the system crash dialog often contains much better debugging information than the friendly messages! Many an XP app that claimed 9x compatibility has crashed on me in a similar fashion. Getting many of these apps to actually run without crashing will probably require much debugging and discussion in a new topic thread....

I tried to do too much in one big step without enough testing. The good news is that I was able to reverse the direction and get the small DLL to forward exports to all the functions in the big DLL. This shows that DLL forwarding does work in Win9x and that fwd is indeed a viable project. I've compared binaries produced by the VC5 linker of a small DLL with and without a single forwarded export and think I can account for every changed bit. I will need to do some more small tests to determine what I am overlooking before progressing to larger tests and then to updating fwd.

Plan D: ComDlgEx.7z ComDlgEx.dll ComDlgEx.reg SumatraPDF 0.9 now loads without Kex, but run with Kex to get past ComCtl32 issues. ComDlgEx.reg REGEDIT4 ;Installation: ; 1) Place ComDlgEx.dll in <winsys> folder ; 2) Copy COMDLG32.DLL to COMDLG99.DLL ; 3) Merge this file into the registry ;Uninstallation: ; 1) Edit comments below and remerge ; 2) Delete COMDLG99.DLL and ComDlgEx.dll [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "COMDLG32"="ComDlgEx.DLL" ;"COMDLG32"="COMDLG32.DLL" ;"COMDLG32"=- ComDlgEx.def ;LIBRARY ComDlg32 EXPORTS xyz=COMDLG99.@100 @100 NONAME ChooseColorA=COMDLG99.ChooseColorA @101 ChooseColorW=COMDLG99.ChooseColorW @102 ChooseFontA=COMDLG99.ChooseFontA @103 ChooseFontW=COMDLG99.ChooseFontW @104 CommDlgExtendedError=COMDLG99.CommDlgExtendedError @105 FindTextA=COMDLG99.FindTextA @106 FindTextW=COMDLG99.FindTextW @107 GetFileTitleA=COMDLG99.GetFileTitleA @108 GetFileTitleW=COMDLG99.GetFileTitleW @109 GetOpenFileNameA=COMDLG99.GetOpenFileNameA @110 GetOpenFileNameW=COMDLG99.GetOpenFileNameW @111 GetSaveFileNameA=COMDLG99.GetSaveFileNameA @112 GetSaveFileNameW=COMDLG99.GetSaveFileNameW @113 LoadAlterBitmap=COMDLG99.LoadAlterBitmap @114 PageSetupDlgA=COMDLG99.PageSetupDlgA @115 PageSetupDlgW=COMDLG99.PageSetupDlgW @116 PrintDlgA=COMDLG99.PrintDlgA @117 PrintDlgW=COMDLG99.PrintDlgW @118 ReplaceTextA=COMDLG99.ReplaceTextA @119 ReplaceTextW=COMDLG99.ReplaceTextW @120 WantArrows=COMDLG99.WantArrows @121 dwLBSubclass=COMDLG99.dwLBSubclass @122 dwOKSubclass=COMDLG99.dwOKSubclass @123 PrintDlgExA @124 PrintDlgExA.c This version was stable (six days). It redirected PrintDlgExA to PrintDlgA and operated as expected if the dialog was cancelled, but did not print.

I downloaded SumatraPDF 0.9 to test with, but couldn't get past the "missing export COMDLG32.DLL:PrintDlgExA" message. My system also became unstable each time I tried the extended COMDLG32, so I've removed the attachment from the previous message pending a complete design review. If it turns out that export-forwarding is an NT-only DLL feature that isn't implemented in the 9x loader...then we'll just have to extend the 9x loader! Since this method was actually something like plan C, I can still go back to plan B (direct function injection). B)

Would you have a link to that version? Only one I can find is the newer version. Search for "rdsk98v5.zip"

For the brave, here is a COMDLG32.DLL with PrintDlgExA: <attachment removed> Extract COMDLG32.DLL and ComDlgEx.dll into <system>, or put them in a test app's local folder and remove COMDLG32.DLL from KnownDLLs. COMDLG32.DLL was extended with fwd.02 (now working, not posted yet). The PrintDlgExA sources (.c + .def) for ComDlgEx.dll are included. I have high confidence in the validity of the export forwarding in this COMDLG32.DLL (Dependency Walker and PEinfo both like it). The structure translation in PrintDlgExA should be good enough to yield positive results. There were seven downloads before I decided to remove the attachment--if anyone has any results at all, please give us all a report!

Manually repackaging drivers is not easy. Any tools to aid that process would be very useful. Perhaps a repository could contain original drivers along with repackaging instructions or a config file(s) for any tool(s) used. For now, anyone who has managed to get a non-9x hardware driver to work on their 9x system, please create a topic thread containing the details (including where to download the original driver).

For years, I've been using John Lajoie's RamDisk98 v0.5, the forerunner to Cenatek Win9xMe 1.5. When programming, I redirect all project intermediate files to ramdisk, greatly speeding the build process. From the readme.txt file: RamDisk98 is a Windows port driver that emulates as fully as possible the low-level functionality of a hard disk (up to 2GB!) or a 1.44MB or 2.88MB floppy drive. The boot sector of the disk is complete enough to permit the disk to be made bootable with the sys command. RamDisk98 is the only RAM disk driver for Windows that allows you to create a bootable disk image in RAM (that I know of anyway). RamDisk98 also supports much larger disks than Microsoft's ramdrive.sys (which is limited to 32MB). The RamDisk98 drive can also be compressed using Windows DriveSpace. For RAM disks configured as hard disks, RamDisk98 can be configured to allow the user to select the drive letter. In addition, RamDisk98 can be configured to automatically load a disk image at startup and save the image to disk at shutdown. This allows the RAM disk to function almost exactly like a hard disk - no data is lost when the power is turned off! In addition, it makes RamDisk98 an ideal tool for creating disk images for bootable CD- ROMs. ... The RAM disk driver core in RamDisk98 is based upon the source code provided with Walter Oney's excellent book Systems Programming for Windows 95 from Microsoft Press. What I did was to pick up where he left off by trying to improve the boot sector initialization of the disk (and fix a few of Walter's bugs) to properly emulate a hard disk or a 1.44MB or 2.88MB floppy drive.

SYS drivers are PE files and can be updated with fwd.01: WDMAUD.SYS imports from KS.SYS; just now I was able to use fwd.01 to add two new functions to KS.SYS. VXD drivers are LE files. I don't know how their imports work, but if they import from any PE files (others drivers or DLLs) they are also supported. Or vice versa, perhaps. Actually, it looks like the two methods will be complementary. (BTW, fwd does not patch drivers, it is a DLL extender.) Dependency Walker seems to think so for KS.SYS exports (imported by WDMAUD.SYS). Or maybe those are only standard exports. Where might I find documentation for "WDM Exports" so I can add support?

MSDOS.SYS Complete Reference Table MSDOS.SYS [Options] BootWarn=0

The number of export functions in a DLL is usually the same as the number of export names. Fwd.01 adjusts all the pointers correctly if this is true. Comdlg32.dll has one more function address pointer than name address and name address ordinal pointers, thus the current issue. Fwd.01 is also limited by the amount of slack space in the logical section following the existing export table. These two issues will be addressed in the next version. In addition to providing an API expansion solution that is complementary to KernelEx for applications, it should also be complementary to WDMSTUB for drivers.