Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


jumper

Kext: DIY KernelEx extensions

Recommended Posts

So far so good. But I'm afraid I've hit a brick wall, now it wants Kernel32:GetLogicalProcessorInformation, which seems to not be supported by anything....

 

 

Add a definition for that function in the kernel32.dll section of your kstub822.ini, reboot and try your program again.

 

For example: GetLogicalProcessorInformation=f2 

 

And make sure you read this topic entirely and thoroughly before you ask any more question as this is something you could have figured out by yourself easily if you had done so. ;)

Share this post


Link to post
Share on other sites

As a programmer, I actually checked first if this is even possible, and I also noticed that the function fills a buffer, so no, kstub is useless here.

 

What I've been trying to figure out, is how to implement such functions myself, i.e. make a simple dll with a function called GetLogicalProcessorInformation and return a preset buffer (Gathered friom debugging and capturing the buffer on an xp installation and figuring out what it does) that the program would only gather from that one CPU core is available and nothing else:

 

ProcessorMask = 1, ProcessorCore = 0, NumaMode = nothing, Cache_Descriptor = 0...

 

Unfortunately no kernel extension projects seem to have such a simple way of doing that....

Share this post


Link to post
Share on other sites

As a programmer, I actually checked first if this is even possible, and I also noticed that the function fills a buffer, so no, kstub is useless here.

 

Is that so? I have GetLogicalProcessorInformation=f2 in my kstub822.ini and it sure allows me to run certain programs...

Share this post


Link to post
Share on other sites

Hi Loblo,

 

I have these 'Get....' in my kstub:

GetFileSizeEx=f2e120 ;D3DX9_43.dll 9.29.952.3111
GetGeoInfoA=z5e
GetGeoInfoW=z5e
GetSystemRegistryQuota=z2e
GetSystemWow64DirectoryA=z2e120
GetSystemWow64DirectoryW=z2e120
GetUserGeoID=t1
GetVolumeNameForVolumeMountPointA=z3e
GetVolumeNameForVolumeMountPointW=z3e

 

Are there more useful ones to add besides GetLogicalProcessorInformation ??

 

Thx, MiKl

Share this post


Link to post
Share on other sites

As a programmer, I actually checked first if this is even possible, and I also noticed that the function fills a buffer, so no, kstub is useless here.

 

What I've been trying to figure out, is how to implement such functions myself, i.e. make a simple dll with a function called GetLogicalProcessorInformation and return a preset buffer (Gathered friom debugging and capturing the buffer on an xp installation and figuring out what it does) that the program would only gather from that one CPU core is available and nothing else:

 

ProcessorMask = 1, ProcessorCore = 0, NumaMode = nothing, Cache_Descriptor = 0...

 

Unfortunately no kernel extension projects seem to have such a simple way of doing that....

My guess is that CPUID may be used to get actual, real information about the current CPU - especially the cache part - which would then be formatted and pasted in the SYSTEM_LOGICAL_PROCESSOR_INFORMATION stucture that GetLogicalProcessorInformation() should return.

 Although most applications may only want to know how many CPU cores/threads are available, some of them may also need the cache details or the NumaNode relationship (where available). To be on the safe side, I think cache information should be accurate and not just filled with some "standard" figures.

 

Simply returning FALSE from a stub may hint the application that it's running on an unsupported system, which may subsequently drive it to just bail out. So it'll be that certain applications would work, others would exit, which doesn't make it the perfect solution.

 

EDIT:

Here's some useful information regarding this API and the structure it's using: NumaExplorer

At the same site there's detailed information on CPUID and its usage: CPUID Explorer (2 pages)

Edited by Drugwash

Share this post


Link to post
Share on other sites

Hi Loblo,

 

I have these 'Get....' in my kstub:

GetFileSizeEx=f2e120 ;D3DX9_43.dll 9.29.952.3111

GetGeoInfoA=z5e

GetGeoInfoW=z5e

GetSystemRegistryQuota=z2e

GetSystemWow64DirectoryA=z2e120

GetSystemWow64DirectoryW=z2e120

GetUserGeoID=t1

GetVolumeNameForVolumeMountPointA=z3e

GetVolumeNameForVolumeMountPointW=z3e

 

Are there more useful ones to add besides GetLogicalProcessorInformation ??

 

Thx, MiKl

 

It's best IMO to add function definitions only as the need for them arises.

Share this post


Link to post
Share on other sites

Using the sources to update KernelEx would be a better idea. But a question arises: when will we stop transforming 9x into NT?

Share this post


Link to post
Share on other sites

Using the sources to update KernelEx would be a better idea. But a question arises: when will we stop transforming 9x into NT?

I think, 98 should be considered 98 while it can run all the applications, compatible with Windows 98 natively. So we should stop only when we break compatibility with older applications. Unfortunately real life shows that we stop much earlier - when developers lose interest.

Share this post


Link to post
Share on other sites

Such topic could easily extend inedefinitely. I see people always asking for compatibility with newer applications and can't stop wondering how many of the older, native-9x ones, are still being used. People always want 'the newest', 'the latest' just to follow the trend, not because they really need that.

 

Of course, there are those 'new standards' that keep being 'upgraded' from time to time for the sole reason of offering leverage to commercial programmers to build and sell new versions of their applications. That's an ever turning wheel, driven by the current economy model at global scale.

 

Then, software is more and more tied to hardware, which gets upgraded for the very same reason as above. Hardware upgrade requires software upgrade, then software upgrade requires hardware upgrade and so on and so forth, while choice has been taken from us constantly until it all became "my way or the highway".

 

At some point we did stop. We had to stop, we can't pursue this madness as much as we'd try. This is a neverending game of greed and power.

 

As I said, we could talk on this topic indefinitely, but this is not the right place and we wouldn't get to an unanymous conclusion anyway. Therefore I stop here, apologyzing for the off-topic.

 

(fixed small grammar issue)

Edited by Drugwash

Share this post


Link to post
Share on other sites

Unfortunately you can't just add NT Functionality without risking 9X Functionality. Many NT API Functions are different in ways that are not compatable. I have even seen Calling conventions changed such as FASTCALL to STDCALL.

This makes it virtually impossible to fully support both.

Share this post


Link to post
Share on other sites

MediaPlayerClassic-Home Cinema (1.6.0.4014) is asking for export-msvcrt.dll: _wsplitpath_s so I added this stub (without def) to kext but my system is then not booting properly. I also tried import-patching the mpc.exe with a msvcrt.dll that has this export function (7.0.6001.18000) but this dll is either too new/incompatible or I am still not doing this patching correctly  :blushing: 

It would be great if some of you could look into this. Thx, MiKl

Share this post


Link to post
Share on other sites

MediaPlayerClassic-Home Cinema (1.6.0.4014) is asking for export-msvcrt.dll: _wsplitpath_s so I added this stub (without def) to kext but my system is then not booting properly. I also tried import-patching the mpc.exe with a msvcrt.dll that has this export function (7.0.6001.18000) but this dll is either too new/incompatible or I am still not doing this patching correctly  :blushing:

It would be great if some of you could look into this. Thx, MiKl

 

Even if you'd manage to overcome this (presumably) Vista and above dependency, you'd encounter many other problems with recent versions of MPC-HC. I managed to get earlier builds to run, using ReactOS uxtheme.dll and some other hacks, but none were fully functional, the best I got was video playback with no audio. Last good MPC-HC version is probably 1.5.1.2903 which most certainly can be configured to use latest Lavfilters (v. 0.63 as of this writing).

 

I think this topic should be stickied btw.

Edited by loblo

Share this post


Link to post
Share on other sites

Thanks Loblo, I didn't even thought about mpc-hc for quite a long time because I used vlc more and more but the vlc-team must have changed something drastically because on their last nightly builds (both in the 2. and 3. line) the gui does not show up ! This may be fixed (for us) when they reach a stable release but I have not much hope.

So, I have downloaded the latest Lavfilters - unpacked & upxed - but I am not sure what to do next. The included install .bat's do not work and I could not manually install the dll's either. What am I missing ? Thx !!

 

Update: install_audio.bat from LAV 0.63 worked on a different PC now. Also install_splitter.bat but from an old version (0.60.1)

Edited by MiKl

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×