I have always wondered why people sometimes use undocumented functions in commercial applications. I can understand using them in your own personal software or freeware or something you are just giving out to a very select few people who all have systems very similar to your own, but why in "professional" software?

I have a few programs, mainly games, which, when run on WindowsXP, try to access certain functions in kernel32.dll which, quite literally, do not exist. I receive error messages telling me that nonexistent functions are being called. ...not unsupported functions, and not deprecated functions...nonexistant functions! They obviously existed in Windows98's kernel32.dll. This leads me to conclude only one thing--that the programmers of those pieces of software chose to use undocumented functions which existed in Windows98's kernel32.dll.

In the first place, that IS the major reason not to use undocumented functions---because those functions might not be in the next release of the windows operating system. They almost certainly won't be implemented in many windows emulators either, being the nature of things undocumented.

I do realize that one reason a programmer might use an undocumented function which he just so happens to find out about is to help accomplish a task or function/feature which might otherwise take him a bit longer to implement himself, but I do believe there are more than enough documented functions that any functionality of the undocumented functions could be duplicated.

Why spend the extra time to reverse-engineer windows dlls for undocumented functions and mess with those when you could probably spend just about as much time to write equivalent code yourself, and then you would have the added benefit of that it would very highly likely be supported on the next release of windows?
Posted on 2003-12-01 00:07:38 by ShortCoder
Yes I think its not a good idea to use undocumented functions but what I would like to know is what are they there for in the first place? Doesn't the OS use these functions? If that's the case then microsoft is not showing a good example of how to program their OS :grin:
Posted on 2003-12-01 04:24:10 by Odyssey
Undocumented functions are there to give an advantage to microsoft products. If you only use documented functions your program will not perform as well as a microsoft equivilant that uses all functions. When a new release of windows comes out all MS software that takes advantage of undocumented functions can easily be updated.
Posted on 2003-12-01 05:45:19 by ENF


Why spend the extra time to reverse-engineer windows dlls for undocumented functions and mess with those when you could probably spend just about as much time to write equivalent code yourself, and then you would have the added benefit of that it would very highly likely be supported on the next release of windows?


Since as you have written man is using undocumented func becouse lack of time to implement something similar, one should have no time to rev-eng them also, so probably he knows about the stuff from some other source.So we are talking about documented-undocumented functions (not officialy ofcourse) :tongue:
Posted on 2003-12-01 13:39:53 by AceEmbler
In systems that never change, like consoles, the coolest thing was to use undocumented functions.
Or take the example of the old home computer Commodore64 from the eighties, which I grew up coding on.
It had these bunch of bugs in it, however, many of there bugs, especially for the graphics chip, could be used for pretty cool graphic
effects, each guy that discovered one of these undocumented "novelities" and presented it first in a demo would be a hero.
I think some of that heritage has carried on from these times, the coolness-factor is still present although now there's no point in it.
So, some difference.
A long time ago it was cool, fast and memory efficient to use selfaltering code ( I refer to 8-bit systems now again ) and it really _was_
usefull to do it then but not now, why??!! The main importance 15 years ago was that every cycle of an opcode counted for the
execution of your computer ( 1mhz processor ) and you had like 64kb of ram. Now ... LOL. Selfaltering would actually be slower.
Then: It was also megacool to use undocumented opcodes, because you could save that extra cycle in your timing, cause could execute two
opcodes within certain circumstances, and also superextracolness would be when the other people wanted to disassemble your code they would not understand it because their lame disassembler could not disassemble those undocumented sequences of code.
So extra plus eliteness for that.
Maybe some of this heritege lives on although it is like not much use now, I don't know. Just my guess..
For using undocumented windows-api's... I would think like to think this, if Microsoft use them in their programs themselves in their programs, why not use them yourself... that just gives me the feeling they did not want anybody to use them but themselves, OR
more belivable -> just they forgot them in their documentation or something.
:alright:

( But I would never use any undocumented stuff ever in my own program because I am too afraid for it to malfunction on another system ............................... so whatever I said that seemed cool was just bullshit LOL :grin: )
Posted on 2003-12-01 17:15:16 by david
I'd say that most user-mode DLL don't contain any undocumented stuff that's worth using...
ntdll and friends is something else, though - there are for instance NTFS features that are not exposed in the win32 api (some of them have been added VERY recently, but thus require xp or win2k3 to use).
However, those facilites have been available through the NT native API for quite some time.

Why didn't MS choose to document the NT native API? I think the 'conspiration theories' have some merit (MS+friends applications having some advantage), but I think it's even more that they didn't want too many people using the native API, and thus locking their apps to just NT, when the official programming standard is the win32 api.
Posted on 2003-12-04 07:04:12 by f0dder
I know for a fact that MSIE has always used a whole raft of undocumented functions to keep it performing faster and better than any other web browser on the system. Probably their Java engine does the same.

Typical corporate shenanigans. That's how businesses maintain their competitive edge.
Posted on 2003-12-04 07:24:22 by Tatterdemalian
Humm, what are those functions? Are we talking undocumented stuff in DLLs like user32/kernel32, NT native api? Or perhaps just undocumented COM interfaces?
Posted on 2003-12-04 08:11:39 by f0dder

I know for a fact that MSIE has always used a whole raft of undocumented functions to keep it performing faster and better than any other web browser on the system.


Evidently, there is something that goes wrong, because MSIE despite their advantages does not perform better at all....:grin:
Posted on 2003-12-04 09:42:25 by pelaillo

Evidently, there is something that goes wrong, because MSIE despite their advantages does not perform better at all....


I have mozilla firebird and thats what I use most of the time but I can't tell if its really faster the internet explorer. Sometimes I think that internet explorer is faster though :grin:. The main reason I use firebird is because of the tab feature. :)
Posted on 2003-12-04 09:47:16 by Odyssey
I run Opera and it is ALWAYS faster...
Posted on 2003-12-04 10:16:18 by pelaillo
Yes, well I use Firebird as well but you cannot avoid IE, MS has made darn sure that you cannot access anything interesting on their site without it. And forget about updates to Windows with a non-Microsoft browser.

For undocumented functions, they can sometimes be useful as shortcuts but you use them at your own risk. They will not always be there and the functionality can change at the whim of Microsoft. Some of them are there to test new functionality within a wide user environment and some are nothing more than custom procedures that MS uses. In some cases these types of undocumented APIs are listed at MSDN and a note saying that no future guarantee of implementation is to be counted on. There are also cases where the docs are not complete, for example in a recent thread about alligning text in a status bar. I had answered that it is done with tabs even thought the STM_SETTEXT message does not mention it, it is a fixed feature of that control.
Posted on 2003-12-04 14:31:34 by donkey