Comment by shubb
13 years ago
One problem that the WINE project (windows emulator for unix)has is that windows is full of undocumented APIs, some of which might be really quite useful, which are used by windows internal developers.
For WINE, if you are going to write an emulator that runs Microsoft code (like the .net framework, or notepad.exe), you need to find the correct behavior of these undocumented APIs by trial and error.
For a developer on Windows, it is perhaps frustrating that MS identifies and solves problems with it's platform, but doesn't publicly release these solutions to you.
I work for some random company that makes an SDK, although I mostly make products using it. Many of our best features are hidden - we don't ship the header files with the SDK, but the symbols are there in the binaries. Someone doesn't think they are useful enough to justify the testing expense for a full release. I guess MS have the same thing.
No. You can complain about insufficiently documented APIs, or internal APIs that you wish you could use but are not documented, but please do not complain about undocumented APIs that are used by Microsoft applications outside of Windows.
Ever since the monopoly rulings against Microsoft, they have had extremely strict internal controls preventing non-OS code from using undocumented APIs. If a DLL or EXE does not ship on the Windows client install disk, it cannot reference APIs which are not documented in MSDN. Full stop.
You're referencing an API that inadvertently didn't get documented, but everyone knows about it, has blogged about it and lots of articles mentioning to use it? Too bad. Either stop using the API or delay release by 3 months for the next MSDN update.
> undocumented APIs
"undocumented APIs" != "a magic combination of function arguments"
Any function that's not documented can be called an undocumented API, any program has them -- Linux, Windows, whatever.
But you were talking about the argument combinations being undefined, not the functions themselves. What are some examples of that?
A bit late, but http://undocumented.ntinternals.net/aindex.html
What about them?
>One problem that the WINE project (windows emulator for unix)
Wine Is Not an Emulator.
What shall we call WINE then? A "pretender"? I'm serious btw. I've never seen a good concise explanation of the way WINE works in comparison to say, an emulator. I have a fairly good idea myself, but I wouldn't want to have to give more than a very brief talk over it.
From the WINE website: "Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop." [1]
[1]http://www.winehq.org/about/
1 reply →
I should have been more specific. How would you introduce WINE to freshmen, not CS students who might need to study WINE in detail, but well, here's a specific case, college freshmen who are expected to install WINE and then install and use software such as LTSpice, DipTrace, etc.? Or, more generally, how to explain it to neophytes who are expected to become moderately sophisticated computer users who might need to use WINE, but will probably never be software devs.
3 replies →
A reverse-engineered implementation of the Win32 API?
2 replies →
It's a set of libraries, and a loader for EXEs and DLLs. That's the simplest, most literal way I can think of to explain it.
@Mike - Yes, that is true enough.