jumper

"Sound Blaster Live" is a marketing brand name for a family of products (chips / boards). "Live" is the version number! The string "SB Live!" is often used instead. Did you find the INF file(s) with PCI ID's (PCI\VEN_1102...)? (Don't expect to find "Sound Blaster Live" in them, but maybe "SB Live".) Perhaps: SBLIVE.inf or OEMEMU.INF also: Ctom10k1.inf, Ctcq10k1.inf , Wsi210k1.inf, kx.inf, wdma10k1.inf....

"About 30,400 results" Including: Is Blogger cutting support for Opera?

The Radeon 9250 (I have a Predator MD-AT9250PC) has hardware DirectX 8.1 and OpenGL 1.3 support. DirectX 9 should use that support and emulate later features in the HEL (hardware emulation layer) without causing a crash.... The digital, analog, and TV outputs have different resolution specs. I have only used analog monitors at 1280 and below and haven't experienced the virtual desktop issue. Consider using a different utility such as MultiRes or HZTool to change/set the desktop resolution. What monitors and utilities have you tried?

Check the PCI ID's for each card against those listed in the CD's INF file(s). See post #1 for the ID's of the CT4780 and CT4830 and instructions on where in the registry to look for the others.

Although we understand what you mean, "USB 1.1 speeds" and "USB 2.0 speeds" is incorrect usage. There is low-speed and full-speed (USB 1.x and 2.0 controllers), and hi-speed (most, but not all, USB 2.0 controllers). I have one PCI USB 2.0 controller that only supports low and full speeds. Perhaps XP doesn't install the driver correctly if the EHCI controller is already configured for hi-speed. Or maybe full-speed is considered more reliable than hi-speed by the Eee PC engineers.

When stubbing, in addition to parameter counts, we also need to know calling convention. If a function uses the Pascal / WINAPI calling convention, the stub must clear the parameters off the stack. If a function uses the "C" calling convention (caller clears parameters off stack), the stub must not. IPstub.dll has a family of WINAPI stubs. When stubbing for a "C" function, the zero-parameter form should be used. (The FASTCALL convention usually passes the first two parameters in registers and the rest on the stack, but is not use when dynamic linking.)

NetApiEx is only marginally related to ImportPatcher, so discussion and updates will continue in [ this Netapi32 topic ]. Thanks, jumper.

NetApiEx was introduced in the ImportPatcher topic, but will continue here. This is a slippery slope...I found over 100 others while researching NetMessageBufferSend. And many of them aren't even in APIParameterCounts! I'll begin adding them in batches. Also, Win9x has in Svrapi.dll ANSII versions of some of the NT Netapi32 functions. A little glue code might allow them to be used as functioning replacements. And also, the Netbios function in Netapi32.dll calls _Netbios in Netbios.dll, so it might be possible for NetApiEx to bypass Netbios and call _Netbios instead.

> This one is working OK but it's not so different than mine since netbios is stubbed and not forwarded. Right. It should be identical to yours, but with another dozen stubs as well. I wanted to avoid the forwarding problem for now, but using it globally in %system% could break other apps that need a working Netbios. > For testing the other one I used a mixture of method 2 and 3 which is to say I did rename your dll to netapi32.dll and did put in the application folder and I also copied to it the original netapi32.dll from the system folder (renamed as NetApi00.dll of course) which theoretically should have been working for the netbios function if I am not mistaken. Should have worked. More testing needs to be done on this front. > Have you succesfully tested a netbios function forwarding and if so can you tell on which program so I can try it out myself? No, I have yet to find a suitable program. The forwarding is produced by the VC5 linker from a .def file the same way that works for the ComDlgEx open and save functions. ...Okay, a brute-force search of my entire 30GB HDD just now found a program named winbox.exe that is static-linked to Netapi32.Netbios. But none linked to the NT Netapi32 functions. I'll do some testing and report back....

Understood. We have a fundamental problem with export forwarders not working, plus a function renaming issue. Using a .def file to tell fwd how to name/rename the new export will prevent the need to use ImportPatcher on every app that links to those new functions. Export forwarding seems to the issue of the day: vilyathegreat and schwups are having success printing with ComDlgEx (but can they "Open File" or "Save As" using export-forwarded functions?) loblo is having trouble with the export-forwarded Netbios function in NetApiEx that is linked the same way as ComDlgEx fwd.03 produces DLLs that still don't seem to work as expected. Looks like I'll have to review and restudy the whole concept of export forwarding and write some very targetted test apps and test cases to determine things like whether KernelEx processing affects link search paths, etc. Any programmers with experience that might be relevant are encouraged to chime in here.

Loblo, you didn't mention which method(s) you tested. I not sure which method is failing or in what mode the dll is having trouble. Here is an updated file with both NetMessageBufferSend and Netbios stubbed. Since this makes it a superset of your stub file, it should work using the same method (2?). Method 4 is where I could use help testing and some feedback. Thanks for testing! NetApiEx2.zip

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. Using a Win2k netapi32 as the primary and a renamed Win9x netapi32 as the secondary should yield a usable netapi32 with both the original Netbios function along with all the NT functions. The next beta of fwd will include support for using a .def file as the secondary. That will allow for such renaming as: NetUserEnum=IPstub.o8

Here's a new stub file designed just for NetApi32.dll issues: NetApiEx.dll - NetApiEx.zip Contains stubs for all missing NetApi32 functions reported anywhere on the web: NetApiBufferFree NetFileGetInfo NetGetDCName NetLocalGroupAddMembers NetServerEnum NetShareGetInfo NetUseAdd NetUseGetInfo NetUserDel NetUserEnum NetUserGetInfo NetUserGetLocalGroups NetWkstaGetInfo All stubs support the proper number of parameters and return ERROR_INVALID_FUNCTION (1). Four ways to use NetApiEx.dll: Place in app or %system% folder and use ImportPatcher to redirect app to it. (for testing mainly) Rename to NetApi32.dll and place in app folder. (local usage; must not be listed in KnownDLLs) Rename to NetApi32.dll and place in %system% folder after renaming original to NetApi00.dll Place in %KernelEx%, add to 'contents' list in Core.ini, and use as a new KernelEx extension: contents=std,kexbases,kexbasen,NetApiEx Yes, you read that right -- NetApiEx contains a KernelEx api_table structure and exports a "get_api_table" function so KernelEx can use it in the same way as kexbasen and kexbases. In fact, NetApiEx is a hybrid. Unlike kexbasen and kexbases which only export get_api_table, it also exports the API functions. This allows it to work without KernelEx ala methods one, two, and three. NetApiEx can be used (in conjunction with NetApi00) as a direct replacement for NetApi32 in %system% (method three) because it also contains an export-forwarder for Netbios, the one native API. Method three will work both with and without KernelEx. Because Net* functions other than Netbios are NT functions, it is very likely that any app needing NetApiEx will also need KernelEx to handle other issues. Hence the appeal of method four.

I'm not a multi-booter, but I believe Win 3.11, 95, and 98 can all coexist if installed to different folders/drives. Then one can boot to DOS and manually (or from a simple batch file menu) invoke the desired OS. If the laptop can boot from USB, multiple external drives (HDD, ZIP, or flash) may be the answer. If the laptop can network boot, ...well, that's over my head! Jaclaz' post was originally #4--there were already two replies. I recall searching the original post #3 for the "wrong" part.

I am beginning work on a configuration tool for KernelEx with these features: Edit registry settings: HKEY_LOCAL_MACHINE\Software\KernelEx + AppSettings - Configs - Flags - KnownDLLs [*] Edit CORE.INI settings: - [ApiConfigurations] + [<OS>] - content, inherit, desc - [<OS>.names] [*] Disable new functions / stubs via CORE.INI -> DCFG1.names -> <module>.<function>=none string hexing in KEXBASEN, KEXBASES This should open the door to adding new and improved functionality to Win9x. New DLLs can extend the API via export forwarders (Link or fwd) or possibly CORE.INI (content, .names). Suggestions for a project name, features, implementation, GUI, usage, etc. are highly desired!

Short answer: Ignore the message and click on the sub-site you want. Most of the sub-sites are flash-based--they'll find the plug-in and load just fine. Long answer: I reproduced the symptoms in FireFox 2.0.0.20 and Opera 10.63 with Flash 9.0.47.0. The scripting Error Console in both browsers report "'$.getScripts' is not a function". The webpage at "skysports.com/score_centre" by default displays the Flash error message and then relies on a script to detect the Flash plug-in and hide the message. The script fails, so the message stays. Searching with Google for "+getScripts -getscript" yielded only two results, so it doesn't seems to be a browser standards-compatibility issue, just a typo/programming error at skysports.com.

Using Dillo-Win32 for this post. MSFN is nearly unreadable because of poor css/frames support. FAQ acknowledges that HTML 4.01 support is still behind Netscape 4 circa 1997! (And development has stopped ) User Agent: Mozilla/4.0 (compatible; Dillo 3.0)Any ideas for a better User Agent string? Tabbed interface uses FLTK. Looks okay with panel size set (in Tools button) to tiny with small icons. Only 1.3MB, so I'll keep it and continue testing for awhile. I'll report back if I'm still using it next week. No javascript, so reply edit menus don't work--must type smiley codes manually:

I've been using this batch file with LOADDR to avoid opening DOS boxes: @%0\..\LOADDR.EXE %1 I'm on SE (BFF7) and realized the Kernel32 base on ME must be different per the error info. Kernel32 doesn't contain relocation data, so must load at its preferred base. Clearly that's different for many versions and apparently in the NT-family has been moved from the Reserved System Arena (Holds ring-0 components) Shared Arena down to the Shared Private Arena [MSKB 125691]. Could you possibly extend LOADDR to also report the preferred base if different? EDIT: Thanks RLoew!

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.

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. Yes, fwd hacks a file without properly hiding its tracks by fixing the checksum! All my tools face this issue. The next version will either zero the checksum, or maybe actually correct it.

According to this link: Google translates the error message to: Palemoon caused an error by a invalid page in module KERNEL32.DLL at 01ef: bff6a4e9 ... Stack dump: 00650050 00000000 004c000c 004c0000 004c985c 00000040 00000000 00000b19 000004ca 0095e748 bff6a6b1 004c0000 004c985c 00000018 00000040 00000013 Subtracting bff60000 from bff6a4e9 and bff6a6b1 and looking up those addresses for Kernel32.dll in Dependency Walker indicates that the error happened in a support function called by IsBadWritePtr. Apps usually load at 00400000, so all those 0040xxxx values on the stack are probably data pointers within Palemoon.

No. "reverse the direction" refers to another method unrelated to fwd. Yes! I finally posted fwd.02 that I was working on last month. I'm not sure what state it was left in, but it has better logging and patching.

What were the error details and Kernel32.dll version? If we cross-reference the instruction address/EIP value with Kernel32.dll function export addresses using a PE viewer, we should be able to determine what function was running. (In the case of your previous post, the Stack dump should reveal what module--and possibly function--might have jumped into unknown memory.) If you have VC++ installed, click on [Debug] in the error dialog to launch it. Then View->Debug Windows->Call Stack to see the calling sequence. I'll try to write a JIT debugger (based on FineSSE) that looks up the call sequence (and maybe offers a live recovery attempt!).

Thanks, bpalone! Indeed, blackwingcat includes code in commonfix.h for the following nine VC++2010 functions that is more complete than KernelEx 4.5.1: EncodePointer DecodePointer FindActCtxSectionStringA FindActCtxSectionStringW HeapQueryInformation HeapSetInformation InitializeCriticalSectionAndSpinCount IsDebuggerPresent IsProcessorFeaturePresent It been awhile since I've browsed in the Win 2000 section; I also found interesting tools from WildBill (PE Tool) and BlackWingCat (PEMaker) and DLL collections from tomasz86 to try out.

I've updated the list with some new project/discussion links. We now have a working solution to printing from apps that call PrintDlgExA or PrintDlgExW.