Stuff that fries your potatoes with olive oil of HAPPY.

[Bobbias]

My point was that if you have a time critical application that is very specific (only going to be used in a very limited environment that isn't likely to change for some time) it might be possible to take advantage of speeding the application up by a little bit by using the Native API, but I never meant that it would be a very widespread thing, either.

And as for my comment on how it changed: There are a LOT of differences between Vista and XP, I realize that they are both NT, and so share most core aspects of the Native API, but technically, they could make a HUGE change in the Native API and still ahve it nearly seamless, because almost every program, aside from essential startup programs and deep parts of the kernel use the WIN32 API instead of the Native API, and they can make drastic changes to the Native API and simply use the same WI32 API to wrap it. That way they can modify the underlaying structure of the Native API without affecting most programs. And compared to the work of writing some of those parts of the kernel that are new in Vista, upgrading a couple essential programs to use slightly different Native API calls wouldn't be much work at all.

My point is that the Native API is pretty much invisible to the end user and since it's so low level, with everything above it, it could be heavily modified with very little outward appearance in the WIN32 API. I never said that they WOULD do that though.

[Spectere]

If you have a time critical application you're NOT going to trust an OS with preemptive multitasking to run it.  Odds are you wouldn't even use PC architecture.

And no, they can't make drastic changes to the Native API because it's a documented API in the DDK.  Microsoft would receive a lot of flak from third-parties if they were to make sweeping changes to it between versions of NT.

[Bobbias]

I didn't realize it was documented in the DDK. Though I should point out that the DDK's documentation isn't complete anyway. (nor is the Native API's documentation anywhere, as far as I know).

[Spectere]

The Native API is documented but is not publicly available from Microsoft.  Third-parties have no doubt partially documented it, but that doesn't say anything for how complete Microsoft's documentation is (and considering how essential complete documentation for such a thing would be to anti-virus and similar vendors, there's no doubt in my mind that it's at least 99% complete).  As I said, documentation is provided with the DDK (and the installable file system SDK, as it turns out) because they sometimes need the ability to run before the Windows API is available.

[Bobbias]

I've heard people saying that even the DDK's documentation is incomplete, and poorly done and such.

There was a hacking group that needed to make a driver that could emulate a hardware dongle to use something that had a complaint in their install documentation saying that it took them something like 3 months just to write the necessary code for making that driver (they knew what the dongle did and such, so it was only the driver code they needed to deal with there really) because of the poor documentation and such. I've no doubt that Microsoft has the Native API fully documented somewhere, but from what I hear, the DDK's documentation is incomplete/poor, and 3rd party documentation is even poorer in some aspects (of course, they probably have documented some previously undocumented functions somewhere).

I've read in more than one place that writing drivers for windows is painful, at best, because of the poor state of the DDK.

[Spectere]

What on earth does any of that have to do with the Native API?  The only way the two are related is that the DDK comes with the Native API documentation.  That is it.

I've heard mixed things about the DDK as well but that doesn't have any impact on the Native API documentation.

[Jupi]

Oh god.  Nerds.

[annon]

Oh god.  Nerds.

OMFG A GURL

[Jupi]

OMFG A GURL

OH MY FUCKING GOD WHERE?!?!?

[OmegaOmni]

THE HELL?

[Jupi]

Oh god you. 

You don't fry my potatoes.


You PEEL them.

[MortifiedocAlot]

Just got a new phone, and it's a LOT nicer then my old one. Apparently I can load MP3s into it, it has bluetooth (which I could use to load MP3S with, right?) and a 1.3 mega pixel camera.

[Zakamiro]

Just got a new phone, and it's a LOT nicer then my old one. Apparently I can load MP3s into it, it has bluetooth (which I could use to load MP3S with, right?) and a 1.3 mega pixel camera.

a razr?

[Bobbias]

What on earth does any of that have to do with the Native API?  The only way the two are related is that the DDK comes with the Native API documentation.  That is it.

And from what I hear, the documentation that comes with the DDK is terrible, I'm going to assume (yes, that evil word) that that would include the Native API documentation.

Fake Edit: I went and did a google search to see what more people had to say.

Comments here bash the DDK's documentation
http://www.amazon.com/Windows-2000-Native-Reference-Circle/dp/1578701996

1 comment here says it's good
http://discuss.fogcreek.com/joelonsoftware2/default.asp?cmd=show&ixPost=64371&ixReplies=12

There are about 240 Native APIs in Windows. Currently, the only documentation on Native APIs is located in the Windows Device Driver Kit (DDK) and the Windows Installable File System Kit (IFS Kit). The DDK actually describes the parameters and usage of a around 25 Native APIs, and includes prototype and parameter information for a few others in NTDDK.H. The IFS Kit documents about 25 more APIS only by providing prototypes in header files that come as part of the kit, and sometimes through their use in sample code. Most of APIs included in the IFS Kit are in the file I/O and security categories. You can find prototypes and some minimal documentation for many Native APIs in the book Windows NT/2000 Native API Reference.

Last year, Macmillan Technical Publishing released a book by Gary Nebbett entitled Windows NT/2000 Native API Reference. This book contains a description of the 10% or so of the native API routines that are documented in the DDK, as well as a long list of undocumented routines that the author sleuthed himself (with apparently no access to the sources). The level of documentation is similar to that found in the MSDN online sources (the function prototype, a description of the function, each of its parameters, and return values, etc). The book could have benefited from some source code examples, but it

[Spectere]

And from what I hear, the documentation that comes with the DDK is terrible, I'm going to assume (yes, that evil word) that that would include the Native API documentation.

Again, Native API != DDK.  They are separate pieces of documentation, evidenced by the fact that the Native API isn't exclusive to the DDK.

Microsoft doesn't exactly want to encourage developers to run around using the Native API because of the potential damage it could do.  It's not intended for general use, hence its limited availability and fairly limited nature.

Just got a new phone, and it's a LOT nicer then my old one. Apparently I can load MP3s into it, it has bluetooth (which I could use to load MP3S with, right?) and a 1.3 mega pixel camera.

Yeah, most phones I've used let you load things to the phone memory via Bluetooth.  If it's a Motorola, you definitely can.

If it has a microSD slot and a mini-USB jack you could generally use it as a card reader by plugging it into the computer.  I have a 1GB microSD card in my V3x and a 2GB microSD card in my BlackBerry for storing media and stuff on, it really comes in handy.

a razr?

If it's a RAZR, it's a V3i or V3m (depending on the network; V3i's work with GSM, V3m's work with CDMA).

Sheesh, I need to stop being a Moto geek...