Windows Internals

[sweetgum]

Does anyone know any good books about windows internals?
I'm actually looking for a book that has information about all the api calls, system calls, and the way exes are loaded. Both of these can be found on the internet, although I just cant find any information about how windows actually loads exes, I know the "jmp" side of things (just jmp to addressofentrypoint) but Im looking for more details, the PE format doc by microsoft has no information about this.

[Love4Boobies]

It's CALL, not JMP that passes control to an application. Applications are normal procedure calls (think of main() if you will -- it returns just like any other function and even has a return value). You will find everyting about the Windows API here. As of for the book on Windows internals, the obvious choice is Windows Internals, 5th ed., Microsoft Press.

[JankoSixta]

When searching the Ralf Brown's interrupt list I found this...
http://www.ctyme.com/intr/rb-4249.htm

Sadly they don't point out which parameters exactly we must specify.

[Love4Boobies]

Even if it would, I wouldn't recommend using those. The whole purpose of using library calls instead of actual system calls is that system calls get deprecated, changed and so on. A system call that's there in one version of Windows might not be the same or might not be there at all in the next. Library calls work around this using whatever system calls are present and provide backward and forward compatibility.

[iammisc]

look at reactos and wine.

http://www.reactos.org/en/index.html
http://www.winehq.org/

That's about as close as you're going to be able to get.

[Craze Frog]

"Linkers and Loaders" by John R. Levine has good information on executable formats, including linking and loading, also on Windows.

[AndrewAPrice]

The whole purpose of using library calls instead of actual system calls is that system calls get deprecated, changed and so on. A system call that's there in one version of Windows might not be the same or might not be there at all in the next. Library calls work around this using whatever system calls are present and provide backward and forward compatibility.

Don't you have this kind of backwards? Windows is known for it's backwards compatibility of legacy code. My 32-bit Vista can run most Windows 3.1 and 95 programs fine. The ones which fail are ones which depend on old libraries I do not have. Where as a Windows 3.1 program will not compile with the latest Windows platform SDK.

Or maybe you are right and the system calls do change and those old programs are dynamically linked to legacy DLLs which are included with Vista. That seems more logical because NT and the 9x Windows kernels most likely had a completely independent set of system calls. I think you are both right and wrong in different way.

[AJ]

Hi,

Love4Boobies and your second paragraph is right. Your compiled Windows programs are dynamically linked with DLL's and the legacy functions are provided there. In this way, the actual structure of system calls can change without the library <--> application interface needing to change. In the same way, a compiled user app may use SYSENTER on Vista running on a newer machine, and INT 0x? on Win95 on an older pc.

Cheers,
Adam

[JankoSixta]

Actually some legacy functions like Yield() from 3.1 as you write, are deprecated and obsolete. Not every though, I - for example, when programming - use WinExec instead of CreateProcess just because it's simpler if you don't need any special creation parameters.

You're running 16bit 3.1 programs on Vista? Well, they need wowexec (16bit NE) or ntvdm (DOS COM, MZ-EXE,...) in NT kernels to work. Vista IIRC doesn't have NTVDM and the DOS command prompt...

[jal]

Vista IIRC doesn't have NTVDM and the DOS command prompt...

Vista 64-bit doesn't have an NTVDM, and Windows ME was the last OS to have an actual DOS prompt (Vista does have a command prompt of course).


JAL

[JankoSixta]

Vista IIRC doesn't have NTVDM and the DOS command prompt...

Windows ME was the last OS to have an actual DOS prompt (Vista does have a command prompt of course).

JAL

Indeed, afaik ME didn't had the choice to reboot to DOS when quitting, apart from 9x.
I don't know about Vista, but it has something named "PowerShell" as a substitute for the "DOS" subsystem NTVDM, but this is a bit offtopic...

[jal]

I don't know about Vista, but it has something named "PowerShell" as a substitute for the "DOS" subsystem NTVDM, but this is a bit offtopic...

cmd.exe, the NT command line interpreter (also present in 2000, XP, Vista and Win7) has always been a native Win32 app, and not DOS (as opposed to the command.com from Win9x/ME). Powershell is a replacement cmd.exe. It is available for XP as well. It has nothing to do with replacing NTVDM, which is something entirely different.


JAL