jumper

It turns out the version of SetDllDirectoryA/W in the master branch was only a rough start by Xeno86 to a partial implementation. It supports setting the Dll Directory search path, but not resetting it by passing NULL as the parameter. I have simplified SetDllDirectory*(...) down to SetEnvironmentVariable*("DLLPATH",...) and also added GetDllDirectory*. Now I'm testing new LoadLibrary* and LoadLibraryEx* code that will use DLLPATH to fully implement WinXP-Win7 alternate DLL search paths. The Win8 functions AddDllDirectory, RemoveDllDirectory, and SetDefaultDllDirectory are a bit tougher and will be added later. For the time being, SetDllDirectoryA/W can be disabled in CORE.INI.

You might also try extracting all files from the installer and simply moving them into place.

Thanks for the BitTorrent report. In the Run 1 stack dump, the only kex addresses are BFA05F90 and BFA075BB in KernelEx.dll. Those portions of KernelEx didn't change between .15 and .16, however if you can reliably reproduce this error, try reverting just KernelEx.dll back to version .15 and report if that makes a difference. Runs 2 and 3 are virtually identical with a GPF occurring when the stack frame spans a page boundary (ESP and EBP are on different 4k pages, 4k=1000h). This is a known problem that goes way back several years at least. In Run 2, the last kex addresses are BFA4A6D5 and BFA4A7B0 (both in Kexbases). BFA4A6D5 appears multiple time in the stack dump, so might be part of some recursion. A DumpPE -disasm on Kexbases.dll reveals that BFA4A6D5 is the entry point for CreateFileA_fix. So the BFA4A6D5 entries on the stack must be parameters or local PROC pointers, not return addresses. BFA4A7B0 is the return address in CreateFileA_fix from the call to the real CreateFileA (CreateFileA_fix pre-processes the parameters and then calls the original CreateFileA to do the actual work). Please check that you have extensions disabled on Kexbases.dll. This portion of Kexbases.dll was not changed in version .16. I see now that the BitTorrent installer is UPXed, if the same is true of the installed app you should unUPX it. UPXed files are not supported yet. Edit: I was able to reproduce the exact error (down to same ESP and EBP). The app self-installs/configures so it is confirmed: UPX is the problem. BT6.4 actually only needs the subsystem changed from 5.0 to 4.0 to work without KernelEx entirely!

I don't think multiple EMMExclude statements are valid. If they are, then EMMExclude=0000-FFFF makes all the others superfluous. Himem/Himemx aren't needed at all. Stacks should probably be 0,0 Many other settings are highly questionable.

The valid load commands for config.sys are DEVICE and DEVICEHIGH for device drivers, and INSTALL for TSR programs. The valid load command for autoexec.bat are LOADHIGH (LH) and LOADFIX. Reading a DVD disc only requires a DVD drive. Playing a DVD video requires commercial software (that may come with a system or video card). Not all apps support the mouse wheel. Not all CD-ROM drives support DMA access.

The project you describe already exists: ReactOS.

Win95 is not supported. The KernelEx 4.5 series only knows how to detect and patch the system loader in 98, SE, and ME.

IdnToAscii isn't missing (it's in Normaliz.dll, a redist.). To what DLL did you add it? On the other hand, RtlIdnToAscii _is_ missing from Kernel32.dll in XP, so that code won't work anyway.

Or just use the Normaliz.dll that comes with IE8. And by the way, RtlIdnToAscii wasn't added to Kernel32.dll until Vista.

It looks like you cross-compiled on a Linux system. Do you have a Windows-based compiler? If you recompile it on Windows without the cygwin and libwine bloat (almost 5MB pre-UPX), it should be much leaner and (hopefully) faster. You might also want to try the Xompie and ReactOS versions of dwmapi.dll.

> FF 53 crashes on extendedXP when i try to type anything . What make you say this? Was there a CrashReporter/error dialog or did FF53 terminate silently?

1 fffd584d [XUL.DLL]106355c0:SetDllDirectoryW(bfa59306) SetDllDirectoryW is called in the main thread and never returns. Instead, the error handler thread (fff22405) gathers information and calls CreateProcessW to launch CrashReporter which returns successfully. SetDllDirectoryW was written by Xeno86 and enabled by Ley0K. The code also looked good to me so I enabled it in .16. Xeno86 didn't leave any clues as to why he didn't enable it. It is an important function, so I'll try to fix it instead of just disabling it again.

If the app is calling ExpandEnvironmentStringsForUser, replacing kernelex\userenv.dll with M()zart's version should fix the %systemroot% expansion problem. But Kernel32, Ntdll, and Shlwapi also contain environment string expansion functions so in all cases adding this to Autoexec.bat should also work: set systemroot=C:\windows Unfortunately, the app shouldn't be assuming Program Files is in your SystemRoot folder. So try this workaround instead to reference off the current folder (real Program Files): set systemroot=.. I was working on Userenv.dll just last week and discovered that M()zart's version is actually much better than the Wine code used in KernelEx. It's just missing a couple of stubs which are easy to add. When I discovered the environment issue is much broader, I temporarily stopped work.

So a 1k resistor between pins 14 and 16 works for the new system where an open connection works for the old system? A larger resistance, a diode in series, or a switch might enable the cable to work on both systems.

The subroutines sub_6161E and sub_AB1E9 are being called as if they takes no parameters. IDA seems to think they take Pascal-style parameters (modifying the stack on return). Which is it? The addresses (61662 and AB2DD) for the endp and following lines are incorrect. > "The application has been completely decompiled." Wrong. It has been disassembled.

My KernelEx updates also contain no Microsoft files or code. And Ley0k's additions appear to be clean, too.

For USB2.0, I'm using the Microsoft stack that comes with Win98se plus NUSB3.3 for the 4.90 and 5.00 files: NEC USB Open Host Controller USB Registry Key: HKEY_LOCAL_MACHINE\enum\PCI\VEN_1033&DEV_0035&SUBSYS_003541FF&REV_41\BUS_00&DEV_09&FUNC_00 Alloc resources: Logical Configuration 0 IRQ: 5 Mask: xFFFF Memory Address Range: Base= xF3FFB000 End= xF3FFBFFF Min= x00000000 Max= xFFFFFFFF Forced resources: None Boot resources: None Filtered resources: Logical Configuration 0 IRQ: 5 Mask: xFFFF Memory Address Range: Base= xF3FFB000 End= xF3FFBFFF Min= x00000000 Max= xFFFFFFFF Basic resources: Logical Configuration 0 IRQ: 0 Mask: xFFFF Memory Address Range: Base= xF3FFB000 End= xF3FFBFFF Min= x00000000 Max= xFFFFFFFF HW Revision: 065 Driver: USB\0022 Driver Date: 4-23-1999 Driver: usbui.dll File Size: 147456 (0x24000) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 Driver: usbhub.sys File Size: 35680 (0x8B60) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 Driver: usbd.sys File Size: 18912 (0x49E0) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 Driver: openhci.sys File Size: 23632 (0x5C50) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 NEC USB Open Host Controller USB Registry Key: HKEY_LOCAL_MACHINE\enum\PCI\VEN_1033&DEV_0035&SUBSYS_003514DB&REV_41\BUS_00&DEV_09&FUNC_01 Alloc resources: Logical Configuration 0 IRQ: 10 Mask: xFFFF Memory Address Range: Base= xF3FFC000 End= xF3FFCFFF Min= x00000000 Max= xFFFFFFFF Forced resources: None Boot resources: None Filtered resources: Logical Configuration 0 IRQ: 10 Mask: xFFFF Memory Address Range: Base= xF3FFC000 End= xF3FFCFFF Min= x00000000 Max= xFFFFFFFF Basic resources: Logical Configuration 0 IRQ: 0 Mask: xFFFF Memory Address Range: Base= xF3FFC000 End= xF3FFCFFF Min= x00000000 Max= xFFFFFFFF HW Revision: 065 Driver: USB\0023 Driver Date: 4-23-1999 Driver: usbui.dll File Size: 147456 (0x24000) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 Driver: usbhub.sys File Size: 35680 (0x8B60) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 Driver: usbd.sys File Size: 18912 (0x49E0) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 Driver: openhci.sys File Size: 23632 (0x5C50) File Date: 4/23/1999 10:22 PM Company Name: Microsoft Corporation File Version: 4.10.2222 NEC uPD720100A USB 2.0 Enhanced Host Controller USB Registry Key: HKEY_LOCAL_MACHINE\enum\PCI\VEN_1033&DEV_00E0&SUBSYS_00E014DB&REV_02\BUS_00&DEV_09&FUNC_02 Alloc resources: Logical Configuration 0 IRQ: 11 Mask: xFFFF Memory Address Range: Base= xF3FFDF00 End= xF3FFDFFF Min= x00000000 Max= xFFFFFFFF Forced resources: None Boot resources: None Filtered resources: Logical Configuration 0 IRQ: 11 Mask: xFFFF Memory Address Range: Base= xF3FFDF00 End= xF3FFDFFF Min= x00000000 Max= xFFFFFFFF Basic resources: Logical Configuration 0 IRQ: 0 Mask: xFFFF Memory Address Range: Base= xF3FFDF00 End= xF3FFDFFF Min= x00000000 Max= xFFFFFFFF HW Revision: 002 Driver: USB\0044 Driver Date: 5-29-2007 Driver: usbport.sys File Size: 135920 (0x212F0) File Date: 11/7/2002 10:42 AM Company Name: Microsoft Corporation File Version: 5.00.2195.5652 Driver: usbehci.sys File Size: 19792 (0x4D50) File Date: 12/12/2003 10:37 AM Company Name: Microsoft Corporation File Version: 5.00.2195.6882 USB Root Hub USB Registry Key: HKEY_LOCAL_MACHINE\enum\USB\ROOT_HUB\PCI&VEN_1033&DEV_0035&SUBSYS_003541FF&REV_41&BUS_00&DEV_09&FUNC_00 Alloc resources: None Forced resources: None Boot resources: None Filtered resources: None Basic resources: None Driver: USB\0024 Driver Date: 4-23-1999 USB Root Hub USB Registry Key: HKEY_LOCAL_MACHINE\enum\USB\ROOT_HUB\PCI&VEN_1033&DEV_0035&SUBSYS_003514DB&REV_41&BUS_00&DEV_09&FUNC_01 Alloc resources: None Forced resources: None Boot resources: None Filtered resources: None Basic resources: None Driver: USB\0043 Driver Date: 4-23-1999 USB 2.0 Root Hub USB Registry Key: HKEY_LOCAL_MACHINE\enum\USB\ROOT_HUB20\PCI&VEN_1033&DEV_00E0&SUBSYS_00E014DB&REV_02&BUS_00&DEV_09&FUNC_02 Alloc resources: None Forced resources: None Boot resources: None Filtered resources: None Basic resources: None Driver: USB\0045 Driver Date: 5-29-2007 Driver: usbhub20.sys File Size: 50032 (0xC370) File Date: 1/16/2004 7:06 PM Company Name: Microsoft Corporation File Version: 5.00.2195.6891 USB Mass Storage Device USB Registry Key: HKEY_LOCAL_MACHINE\enum\USB\VID_154B&PID_FA05\IN140131000001 Alloc resources: None Forced resources: None Boot resources: None Filtered resources: None Basic resources: None Driver: USB\0041 Driver Date: 11-16-2007 Driver: USBNTMAP.SYS File Size: 7136 (0x1BE0) File Date: 2/17/2003 6:29 AM Company Name: Microsoft Corporation File Version: 4.90.3000 Driver: USBSTOR.SYS File Size: 21040 (0x5230) File Date: 2/17/2003 6:29 AM Company Name: Microsoft Corporation File Version: 4.90.3000.1 I can read 5-10MBytes/s from a flash drive--definitely USB2 "High Speed". The Mass Storage driver won't affect USB networking, but some of the others probably do. Security type probably does affect speed. The drivers have to encrypt/decrypt each packet sent/received if it isn't handled by the chip (unlikely in low-cost products).

> [T]he [POSReady '09] IE8 update (and probably earlier versions) fix a couple of issues most of the Internet says "cannot" be fixed on IE8 on XP: > ... > * Adds AES support to IE8 (AES was added to schannel.dll many updates ago, but IE8 wouldn't use it) Are there direct download links for these updates? Thanks.

The top-left corner of a window is always (0, 0), so it is impossible to resize a window from the top down. To get the effect you want, first you must reduce the height of the window and then move all the contents upward (child windows A and B in this case). If you have trouble moving "A" to a negative location, move it below "B" instead.

Intel, NEC, and VIA all provide USB2.0 support in the drivers for their Win9x-compatible USB chipsets. Intel is supposed to be the fastest. My SiS-based machine only has USB 1.1 onboard, but I remember getting 4Mbits sustained downloads in the past with my Airlink101 USB wifi dongle. Yesterday I peaked at 5Mbits via my NIC-connected (SiS 900 PCI Fast Ethernet Adapter) external Wifi modem (also Airlink101). Win9x will definitely do some higher speeds if you get your Receive Window and other network parameters tweaked correctly.

I think you might be hitting yourself with a DOS attack. Try reducing the number of addresses you ping in each batch. What is the minimum number of pings that breaks the streaming connection? You can also try adding a pause between pings in the batch file. For Advanced IP Scanner, try reducing its execution priority and also see if it can be configured to run in a background mode with lower priority and/or slower ping rate. Yes, there are network registry settings to try. Google can point the way.

What about the Platform Update for Vista that Microsoft released in 2009 (and refreshed in 2011)? It adds Win7.0 API support to Vista SP2.

The modified 0.9.8 package contains three small source files--one for OpenSSL_add_all_algorithms and one for each of the two patches. Very simple. If I can recreate the modified package using MSVC6, then it should be easy to update it with three more 2007 patches listed at http://web.archive.org/web/*/http://www.openssl.org/news/*. The changelog states: We can probably port the old init code (with lock) forward, or do it in the DLL init. If so, we might be able to go all the way to 0.9.8zh....

Thanks, supem. Can you tell us more about the printpdf@pavlov.net and printedit@DW-dev add-ons you have installed? Describe your usual method of printing including what you see at each point of the print process. Use Dependency Walker to determine what Winspool.drv API's are used by FF and the print add-ons. Also which PrintDlg* functions from Comdlg32.dll. In Core.ini, what is your contents definition? For example: contents=std,Kstub822,kexbasen,kexbases

@schwups: please test printing. Not having a printer installed is an important test case! @MiKl: Was this after the print dialog closed? Which print dialog and winspool functions were called?