An actual assembly programming question

[hutch--]

 :bg

> i wonder what you guys think the kernel is - lol

I always thought the "Colonel" had something to do with Kentucky Fried Chicken.

[dedndave]

some example code from microsoft....

http://msdn.microsoft.com/en-us/library/ms724429%28VS.85%29.aspx

would you like a hot apple turnover with that ?
perhaps i could interest you in some nice crow

[hutch--]

 :bg

Ah, here is a man who has not sufered Microsoft changes from Win3.0, 3.1, NT4, Win95oem, Win95a, Win95b, Win95c, Win98, Win98se, Win2000, WinXP (SP1/2/3) Vista, Win7 etc ....

We would both grow old listing the changes across this many versions and remember that from Vista onwards the old NT "Colonel" is no longer used. The experience would not be "Finga likkin good".  :P

[dedndave]

well - you can't write all your code for some non-existant OS - lol
are you telling me that vista and win 7 do not use kernel32.dll ???

[oex]

well - you can't write all your code for some non-existant OS - lol

Sounds like heaven to me.... Just think of al the bugs er features you wouldnt have to work around :lol

[baltoro]

WOW,...this is great !!!
Thanks guys for all the information,...
...I think the code in drizz's response is what I'm looking for.

And, here's the reason I asked: I'm writing a DLL component in assembly language that determines processor characteristics, Operating System version, and security context information. I'm translating a component class that I wrote in C++. To improve on my original class. I'm adding various code blocks that I've located by searching the MASM forums,...just attributing the various code blocks to the original coders is taking up alot of the actual space in my asm file. For example: I've shamlessly stolen this cool concept: CPU Identification Code, from Antariy (actually, I sent him a forum message, and he says it's OK with him). 
The basic concept is to have a working code library that works correctly for any Windows Operating system, from Windows 95 on. So, yes, kernel32.dll is loaded into all process address spaces, but, if I am running on, say, Windows XP, and I call this function (GetProductInfo) in my code, it will FAIL. I think it will actually fail to compile, because the MASM32 header files don't prototype the function, and the current libraries I have installed on my computer (I'm still running Windows XP) don't export this function. Hence, the LoadLibrary and GetProcAddress approach, which (and, even Microsoft recommends this technique in their documentation) should work on all Windows versions, even Windows Vista and Windows 7. On previous operating systems I have a conditional code block that executes if GetProcAddress fails.
The reason I posted the question is that this situation comes up repeatedly, especially in respect to the User's security context.
The component is meant to be used as a preliminary scan of the overall system characteristics that might be significant from the general functionality of a program's execution. It's not really a good way to determine what specific functionality is available. Hutch is right about that,...you should use the LoadLibrary/GetProcAddress method for any of your application's critical requirements.

[hutch--]

baltoro,

To satisfy the recent windows versions in security terms make sure you use a version control info block for the DLL so that the OS can recognise it and the shitty end of AV scanners have something to work on. A manifest file also helps in terms of recognition.

[baltoro]

To satisfy the recent windows versions in security terms make sure you use a version control info block for the DLL so that the OS can recognise it and the shitty end of AV scanners have something to work on. A manifest file also helps in terms of recognition.

...that hadn't even occurred to me. Thanks again.