I see. I had only briefly read about it and never tried it myself so I had assumed it was a full working fork.Originally Posted by adeyblue
Thank you for the information and the code. I will have a look at it when I have some spare time.
I see. I had only briefly read about it and never tried it myself so I had assumed it was a full working fork.
Thank you for the information and the code. I will have a look at it when I have some spare time.
Yeah, that's one thing I hate about some API's. They're just typedef's wrapped in typedef's wrapped in typedef's. I always want to tear them apart to see what their underlying structure is...I know I shouldn't, that's the purpose of them, but I guess it just eats away at me not knowing what it is I'm working with. They always go overboard with the typedef's in Win32API - I learned that when I first started tinkering with it - before I actually had to use it for anything constructive.While it may look like an UNC path it is not. It's a namespace prefix to let windows know which subsystem that should handle the file request and if the file path should be preprocessed before being sent of further down the API chain.
See the namespace sections at Naming Files, Paths, and Namespaces (Windows) for more information.
You can for example also access individual partitions with \\.\Device\Harddisk<n>\Partition<n>
You might also want to try the winobj application linked from that msdn page above if you want to see what's in the different namespaces. (run as admin under vista/win7 or there will be items missing) Everything under GLOBAL should be accessible from user land.
The NT API is very interesting beast to play with but sadly most of it has very little, if any, documentation. For example, NT has native support for a fork()-like API call but I don't think it's officially documented anywhere.
Edit:
Oh, and I just remembered where I've seen HANDLEs used as real pointers.. GetModuleHandle(), which returns a pointer to where a DLL/EXE is loaded in to memory.
It returns a HMODULE, which is a typedef for HINSTANCE, which is a typedef for HANDLE, which is a typedef for PVOID, which is a typedef for void*. Feels kind of like the designer of the win32 API had just learned about the typedef keyword and went a little overboard
It's sad that sometimes documentation from MS is so hard to find..but it seems, in my opinion, anyway, that they've pretty much gave the big "fu8k you" to C/C++ to focus all their efforts on C#/.NET in terms of building applications for the desktop/laptop platform - I think their smart phone too... Poor documentation sucks - that's what makes POSIX so nice :-\. Pfff, fork, not like anybody uses it anyway O.o.
As for the UNC, I'll have to look at it later tonight, but could you do a similar thing with the block devices /dev/hdXX or /dev/sdXX on a Linux based system (using fopen)?
Yeah, but as far as I know you can't memcpy from a file handle anyway, it would just steal the struct. It just seemed as though people were saying they could snag access to the raw file pointer - which confused the hell out of me as on most UNIX based systems it points to an OS struct, and you simply get a pointer to that which is the file descriptor. Guessing the same just applies here.
What you are seeing is the evolution of the OS. No company in there right mind scraps a project and starts from scratch. If you actually follow the API typedef chain and compare it with the various versions of Windows, you can see the progression. It is actually quite brilliant, albeit confusing at points.
msdn.com - It is all right there. True it is not easy if you are just getting into the API, however I guarantee you everything you need to use is documented and readily available.
Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.
Yeah, pretty rarely am I *not* able to find stuff on the MSDN documentation, though I suppose you're right. On the flipside, wrapping a typedef of a pointer in another typedef is just pointless, IMO. If it's still pointing to the same thing, I say leave it the way it is :-\. Fortunately or unfortunately, I don't 'live' in the Windows API (I don't make Windows desktop software), but it's still nice when things are coherent, lol. Though, I suppose, as you said, it's just the evolution of the OS, not much I can do about it.
True words.
First off... amost all documentation for Windows API is on MSDN... you just got to know how to search it.
If you're looking for code samples and such... download the Windows SDK and have it all local on your hard disk.
UNC refers to the Universal Naming Convention used on local area networks for file sharing.
Yep... the handle is actually the address of a struct burried someplace in the Windows runtime.... (just like Window handles, etc.)Yeah, but as far as I know you can't memcpy from a file handle anyway, it would just steal the struct. It just seemed as though people were saying they could snag access to the raw file pointer - which confused the hell out of me as on most UNIX based systems it points to an OS struct, and you simply get a pointer to that which is the file descriptor. Guessing the same just applies here.
Conversely ... I'd never written a Windows Console program until I started posting here...
I learned C at the same time I was learning Windows API...
The reason for all the typedefs is just like Andrew and you said, the evolution of the OS. And also ease of code maintenance.
Say the underlying type for HANDLE changes in some future windows version. With the current design they only need to change 1 typedef, that of HANDLE, and all the "child" typedefs change automatically as well. If they had typedef'ed them all to void* individually it would take a lot more changes and it would be easier to make a mistake and forget to update one of them.
As for the (lack of) documentation, everything about the public APIs is documented on msdn. The reason the native NT API isn't documented is that Microsoft makes no promises that it won't change between windows versions.
You can search unofficial documentation or reverse the functions by yourself and use them, but then you should also be aware of the risks and not blame Microsoft if your software breaks after a service pack or even a small patch
Ah, didn't know they had examples in the SDK O.O! Typically, after looking at the MSDN docs, I just google examples, and they're typically common enough that it comes right up.
Yeah, I just looked up the wiki on it, I wasn't aware that it could include devices such as HDD's or serial ports.
Ah, I see. I learned C in the POSIX environment on Solaris in college. Due to the "development driven" nature of UNIX based systems, as many others seem to, I find Linux "better" for programming, or using Cygwin or MinGW in Windows, opposed to using the Win32 API. Though lately for some reason (too much working on sub-app level stuff in Windows I guess) I think I'm now more inclined to use the Win32 API for app level Windows programming as it's required for the lower end, for the higher end (applications)...which is probably a good thing.. Though I'm not an active app level Win32 developer, I think at this point if I needed to make an app, it would either A) Rely on an existing toolkit (I'm favorable to QT), or B) Use the Win32 API. - oppose to trying to use Cygwin or something to try and "froce" a UNIX-type environment in a place where it's not native.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @ ANYBODY: MY THOUGHTS ONLY - not looking to start a debate about them. I'm not making any claims that one way is better than the other, or that people should or shouldn't use one way.
Why's that? Everything from Win NT to Win7 is part of the NT kernel/OS family. I would think should be the *most* documented API. I guess that's why stuff breaks between XP and Vista or Vista and 7 I suppose.As for the (lack of) documentation, everything about the public APIs is documented on msdn. The reason the native NT API isn't documented is that Microsoft makes no promises that it won't change between windows versions.
You can search unofficial documentation or reverse the functions by yourself and use them, but then you should also be aware of the risks and not blame Microsoft if your software breaks after a service pack or even a small patch
Yeah, I don't really know what is in the NT API, I only look at the Win32 API for Windows, and as you, others, and I have said, it's all there. Don't think I've ever *not* found anything I was looking for there...
..except an fgets alternative *sigh*
