I know I need to call wglGetProcAddress to get the address of the extension wglSwapIntervalEXT. Assuming the call to wglGetProcAddress succeeds, is wglSwapIntervalEXT located in opengl32.lib?
wglSwapIntervalEXT located in opengl32.lib?
No.
opengl32.dll is basically a trampoline into the actual OpenGL implementation provided by the GPU driver, the so called ICD (Independent Cient Driver). It also contains a software rasterizer, but that's just a fallback.
opengl32.lib is just sort of a table of contents for the DLL.
Related
I'm going try to experiment C# with OpenGL modern driver in Windows 10 and I'm trying to find it.
As I have understand the standard driver Openg32.dll, which is located at %systemroot%\system32 is an old one and seems to be it's from Microsoft, am I right?
I came to this conclusion, because of using the next command:
dumpbin opengl32.dll /exports
And found the function:
11 A 00090330 glBegin
As I remember, this function as glLoadIdentity, glMultMatrix, glTranslate, glRotate are deprecated and NOT included since OpenGL 3.2+, because you have to do matrix math on your own & use shaders.
OK, I begin to search at NVidia directory (the vendor of my video card is NVidia) C:\Program Files\NVIDIA Corporation, but have found only OpenCL drivers C:\Program Files\NVIDIA Corporation\OpenCL:
OpenCL.dll
OpenCL64.dll
Any of them is perfectly dumped via: dumpbin /exports
But I can't find here the OpenGL driver exactly. Maybe it has some specific name like nvdisps.dll or something else?
PS (if you ask me about)
I know about, that it's more recommended to use C++ for this stuff
I don't want to use already done libraries
I want P/Invoke stuff and just try to do it with C#
The opengl32.dll acts as a "conduit" toward the actual OpenGL driver, the so called "ICD" (Installable Client Driver); it also contains OpenGL-1.1 fallback code, since OpenGL has been part of the Win32-API application binary interface contract (i.e. programs running on Win95b or WinNT-4 or later can expect a working OpenGL-1.1 implementation).
The vendor ICD registers itself (in the Windows registry, for details see https://msdn.microsoft.com/en-us/library/windows/hardware/ff568203%28v=vs.85%29.aspx) and the opengl32.dll loads the appropriate ICD. The name of the ICD is not fixed. You can easily find the used ICD, by passing an invalid pointer to a OpenGL function that expects a buffer; the access violation will happen inside the ICD's code.
I had been setting my application (MASM assembly language program) entry point via Visual Studio configurations, in the Project properties as:
Linker\System\SubSystem: Windows (/SUBSYSTEM:WINDOWS)
Linker\Advanced\Entry Point: WinMain
Any my main proc called WinMain (matching the above setting). It is a basic application that makes simple Windows API calls, e.g. MessageBoxA... and it works.
Now I'm building a Window application (in assembly), I read somewhere that I need to call the WinMain Windows API for an entry point.
I'm now confused! Which technique do I use to set the entry point to my application (exe)? The Windows API call 'WinMain' or the Visual Studio Linker entry point settings? And is the difference, i.e. C++ runtime vs OS?
If you are using the C runtime library (which is usually the case when programming in C) then you must not specify the linker entry point yourself. If you do, the runtime library will not be properly initialized, and any runtime library calls (including those inserted by the compiler) may fail.
Instead, your main function should correspond to the relevant standard: WinMain() for a GUI application, or main() for a console application.
In an assembly language program that is not linked to the C runtime library, you should specify an entry point of your choosing.
The signature of the native entry point is
DWORD CALLBACK RawEntryPoint(void);
Important:
Returning from the raw entry point implicitly calls ExitThread (see this answer) which is not usually the right thing to do, because if the Windows API has created any threads that you don't know about, the process won't exit until they do. Note that the Windows API documentation does not always indicate when a particular API function may cause a thread to be created.
Instead, you should explicitly call ExitProcess. This is what the C runtime library does when you return from WinMain() or main().
Last time I described my problem badly.
Now I'll try to explain my problem clearer.
I'm trying to make HDD serial checking to prevent distribution of the program. I don't have its src, so I found some space in .code section and injected code there.
You can see intermodular calls. For example, call kernel32.GetDriveTypeA matches call 75738D98. BUT after reboot this address changes. However my code calls incorrect 75738D98 address.
I need to fix it (resolve new GetDriveTypeA address and replace 75738D98 with correct address)
LoadLibrary and GetProcAddress will give you the address to a DLL function. The next natural question is: how can you call LoadLibrary and GetProcAddress if you don't know their address?
All user processes have kernel32 loaded. You don't need to dynamically load anything in kernel32.
Normally your linker & the OS loader does this all for you by linking to an import library (kernel32.lib for example). This will tell the OS that you want kernel32 loaded with your DLL. Your DLL has a import address table which contains a bunch of stubs to the real imported functions. When your module is loaded, the OS patches these stubs to point to the real function address.
You should probably be doing it this way too. Your app can even be detected as malware if you try to get too hackery.
Do you have a good reason not to just link to the import lib?
I need to differ two binary files - a driver and a common dll. As far as I understand I need to view sections of this files (e.g. via DumpBin) and see if there is an INIT section. Is this criteria complete?
You need to parse the binary and look into Subsystem filed of IMAGE_OPTIONAL_HEADER, if it's NATIVE, then it's a driver. Look into the following link for details:
http://msdn.microsoft.com/en-us/library/ms809762.aspx
You would have to use heuristics to establish this fact and be certain to the extent possible. The problem is that there literally exist native user-mode programs (e.g. autochk.exe) and DLLs (frankly nothing comes to mind off hand, but I've seen them as part of native programs that do stuff before winlogon.exe gets to run) as well as kernel-mode counterparts (bootvid.dll, hal.dll and the kernel in one of its various forms ntoskrnl.exe).
So to establish it is a driver you could try the following:
IMAGE_OPTIONAL_HEADER::SubSystem, as pointed out, should signify that it's "native" (i.e. has no subsystem: IMAGE_SUBSYSTEM_NATIVE)
Verify that the IMAGE_FILE_HEADER::Characteristics is not DLL (which would mean it's a kernel or user mode DLL, check against IMAGE_FILE_DLL)
Make sure it does or does not import ntdll.dll or another user mode DLL or to the contrary that it imports one of the kernel mode modules (ntoskrnl.exe, hal.dll, bootvid.dll) to establish whether it would run in kernel or user mode.
The structs and defines are all included in winnt.h.
The gist:
establish the subsystem (only IMAGE_SUBSYSTEM_NATIVE is interesting for your case)
establish it is a DLL or not
establish whether it links against user or kernel mode components
I just want to ask, I know that standart system calls in Linux are done by int instruction pointing into Interrupt Vector Table. I assume this is similiar on Windows. But, how do you call some higher-level specific system routines? Such as how do you tell Windows to create a window? I know this is handled by the code in the dll, but what actually happend at assembler-instruction level? Does the routine in dll calls software interrupt by int instruction, or is there any different approach to handle this? Thanks.
Making a Win32 call to create a window is not really related to an interrupt. The client application is already linked with the .dll that provides the call which exposes the address for the linker to use. Since you are asking about the difference in calling mechanism, I'm limiting the discussion here to those Win32 calls that are available to any application as opposed to kernel-level calls or device drivers. At an assembly language level, it would be the same as any other function call since most Win32 calls are user-level calls which internally make the needed kernel calls. The linker provides the address of the Win32 function as the target for some sort of branching instruction, the specifics would depend on the compiler.
[Edit]
It looks like you are right about the interrupts and the int. vector table. CodeGuru has a good article with the OS details on how NT kernel calls work. Link:
http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8035
Windows doesn't let you call system calls directly because system call numbers can change between builds, if a new system call gets added the others can shift forward or if a system call gets removed others can shift backwards. So to maintain backwards compatability you call the win32 or native functions in DLLs.
Now there are 2 groups of system calls, those serviced by the kernel (ntoskrnl) and by the win32 kernel layer (win32k).
Kernel system call stubs are easily accessible from ntdll.dll, while win32k ones are not exported, they're private within user32.dll. Those stubs contain the system call number and the actual system call instruction which does the job.
So if you wanted to create a window, you'd call CreateWindow in user32.dll, then the extended version CreateWindowEx gets called for backwards compatability, that calls the private system call stub NtUserCreateWindowEx, which invokes code within the win32k window manager.