Talk:Windows API

From Wikipedia, the free encyclopedia
  (Redirected from Talk:Windows.pas)
Jump to: navigation, search
WikiProject Microsoft Windows / Computing  (Rated B-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing (marked as High-importance).
edit·history·watch·refresh Stock post message.svg To-do list for Windows API:
  • give some info on the .net framework and WinFX and its relation to the Windows API
  • check the compiler support section for facts and add references
  • expand some of the Versions entries a bit, and make them a bit more uniform
  • reword the leader slightly (I still think it could be clearer, maybe by giving some short examples of what it does, understandable to non programmer windows users)
  • add a paragraph on the win16->win32 move in the API and the introduction of a 64-bit version of the API to the history section
  • add a short section on "the anatomy of an average Windows API application", just going through the basic concepts, like:
    • the message based system you have in the WinAPI, with callback functions and everything
    • the object-oriented inspired window classes system
    • exactly what a "window" is in the context of the WinAPI (just about everything from windows to buttons)
    • emphasis on short, this should not get to "function names" level, like it was before
      • the link "Windows API Code Pack for Microsoft .NET Framework is a .Net wrapper library for Windows API." no longer exists as of 2/10/2016

API or rather ABI?[edit]

An API serves source code portability, it results in being able to compile, then execute programs. The same API can be maintained over multiple instruction sets, e.g. x86, ARM and Power Architecture. An ABI server binary portability, it results in being able to execute already compiled programs. It is not possible to have the same ABI over different Instruction sets!

This is absolutely not the same. It is much harder to implement and maintain an ABI. In case you want to run already compiled programs, Adobe Photoshop or some Video game, you care about the ABI. ScotXW (talk) 12:02, 27 February 2014 (UTC)

Internet Explorer Integration[edit]

"Internet Explorer has been an integrated component of the operating system since Windows 98, and provides web related services to applications [10]. The integration will stop with Windows Vista."

This seems to contradict Microsoft's publications

Windows API not property of Microsoft[edit]

"Windows API is basically considered not the property of Microsoft as is its implementation."

What does this mean?
Better now? -- Tim Starling 01:43 26 May 2003 (UTC)


This "function" is actually a macro that calls the ExitWindowsEx function. I propose removing it from the list to avoid confusion early on. We could replace it with a function that is more commonly used, as this function is not very commonly used by applications developers anyway. SteveS 22:07, 29 Jan 2005 (UTC)


The history section here does not make much sense grammatically and needs expansion and cleanup. Dsav 06:41, 28 Apr 2005 (UTC)

Opinion, much?[edit]

"However, in general, the interface remained fairly consistent, and an old Windows 1.0 application will still look familiar to a programmer who is used to the modern Windows API.[14]" I love how if you look at reference 14, it's a book written in 1998. Yes, clearly modern (2009) programmers will think Windows 1.0 applications look "familiar." —Preceding unsigned comment added by (talk) 20:33, 29 July 2009 (UTC)

clean up?[edit]

For such a widely used api, this page seems to be a bit barren. I'm going to see how much I can clean it up in a few weeks, because I can see why the cleanup tag was added. I certainly wouldn't mind it if anyone was looking over my shoulder while I do so, since I am rather new to wikipedia writing :).--Codemonkey 09:49, 19 August 2005 (UTC)

I completely rewrote the history section. I still have to add a paragraph on the big win16->win32 move and the introduction of a 64-bit version of the API. Overall though, I've tried to err on the side of too much information, so some of it may need to be trimmed down a bit eventually. Any comments, if anyone is reading this, would be appreciated. --Codemonkey 16:42, 27 August 2005 (UTC)
If nobody objects, I'm going to remove the cleanup tag in a couple of days. --Codemonkey 18:43, 29 August 2005 (UTC)
I've gone ahead and removed the cleanup tag. I'm not quite finished with this article yet, but I think it has been cleaned up enough to warrant removal of the tag. If anyone disagrees, feel free to put the cleanup tag back up again. --Codemonkey 17:20, 4 September 2005 (UTC)
Hey I tried clarifying a small thing in the introduction for beginners who want to learn the Win32 API but don't quite understand what it is. 04:09, 28 August 2007 (UTC)

To do[edit]

I've had a short to do list for a while on my userpage on what I still wanted to do on this article. I haven't had too much time to do it, so I've moved it over to this page, and expanded it a bit. Feel free to add to the list, or make comments if I listed something stupid on it. Also, for reference, I got this reply on my userpage todo list: User talk:Codemonkey#WinAPI_compiler_support, from User:tyomitch. --Codemonkey 20:15, 8 October 2005 (UTC)


Doesn't the .NET winFX unnecessarily complicate it? Pretty much the only thing they have in common are that they are "an" API and run on "Windows" (and the latter even is not fully decided). "The windows API" is the native one. The .NET api's are different ones, I'd keep that apart.

Yeah, I'd agree. The "Windows API" to me means the C/C++ and maybe the VB APIs, but .NET is entirely new and is no more "Windows" than Java is. The only parts that are really Win32 specific are S.W.F and some of the low level OS semantics. Maybe that section should just be dropped, or rewritten to point to the main .net article?
Yes, I also agree. I just removed a paragraph about Mono (mentioned as Win API implementation in error). .NET is (like Java or Mono) a platform independent virtual machine and object-oriented application framework. See, Windows API has nothing to do with a virtual machine at all and doesn't encapsulate functionality into objects. .NET is on the other hand not mandatory depending on Windows API. Of course it uses native API of the host OS, but that may be an API under Linux or Mac (as soon as .NET supports those systems), too. Furthermore, .NET does not allow to do all you can do with the Windows API, because some of the Windows API functions are (of course) not platform independend and also considered "unsafe". This diskussion shows there is confusion about Windows API and .NET. So in my opinion it would make sense to clearly state how different they are. .NET is no "Windows API Version 2". -- 21:10, 8 August 2006 (UTC)

As there is great demand on mentioning .NET in the article, I put a note about .NET into the "Wrapper Libraries" section. .NET wrapps many of the Windows API functions, like all application frameworks and programming languages under windows do. Maybe (someday) Microsoft will merge the Windows API into .NET, but that's not relevant today. Maybe Microsoft also will merge the Native API into .NET someday, if mankind persists on earth long enough. No need to diskuss that in this article. ;) -- 09:10, 10 August 2006 (UTC)

Other implementations[edit]

I removed the citation needed tag from this section - it *is* generally accepted (I have worked on the leading reimplementation of Win32 for years), although if you wanted the legal precedence for this you would have to dig out the Sega case where it was shown that header files cannot be copyrighted.

More specifically, you cannot legally copyright an interface, only an implementation (which the Sega dispute formalised in case law). Therefore because Win32 is an interface (usually but not always paired with the Windows implementation) you can reimplement it legally.

Again I am not sure what you could cite to prove this in the case of Win32 specifically. It's just how copyright law works.

MikeHearn 11:13, 4 September 2006 (UTC)

IMimeMessage merge[edit]

I don't think IMimeMessage should be merged here; instead, I think the IMimeMessage article should be deleted. -- Mikeblas 16:45, 21 November 2006 (UTC)

See bug 9660 - this article shows a bug in Mediawiki[edit]

Ta bu shi da yu 06:52, 22 April 2007 (UTC)

That's not a bug. The colon after the title, before the reference, is the delineation between the <dd> and <dt> tags. I've moved the colons so that it looks a bit better. -/- Warren 07:10, 22 April 2007 (UTC)

Is Win32 still a trademark?[edit]

If so, shouldn't this be mentioned in the article, since Win32 redirects here? -andy 16:28, 10 October 2007 (UTC)

Where can we download it?[edit]

I am a beginner learning C++.

I think it would be important to include a link or some kind of direction as to where this API's files can be found so people like me can start learning it.

Where do I get the file(s) for Windows API? Is it a secret? No web site I can find seems to know.... —Preceding unsigned comment added by (talk) 23:49, 27 December 2007 (UTC)

according to the article, they are in built in to windows. Just find a compiler that supports them i think. that is normally the case with API's i believe. 12:01, 7 May 2008 (UTC) —Preceding unsigned comment added by Oxinabox (talkcontribs)
The API is built right into Windows, so if you have Windows, you already got it. But to have compilers you need, you need the headers and associated tools that describe the API to the compiler. This is available as a part of the Windows SDK ( [1] ). You can use that with the Visual C++ line of compilers and Microsoft Visual Studio IDE (including VC++ Express [2]). This blog post explains how to use Windows SDK with VC++ Express 2008. The Windows SDK, however, won't allow you to use MinGW or GCC compilers. Use the MinGW Windows runtime/api for an analogous functionality. --soum talk 12:29, 7 May 2008 (UTC)

API articles[edit]

These individual API/dll subsections need articles of their own, and should also be organized in part according to implementation (in/outside of kernel, "nt exec", some service, system library, etc). anyone have any ideas for how to do this, or votive to start an article? (talk) 06:17, 18 February 2010 (UTC) not an ip -- not signed in

No any date per whole article.[edit]

Per whole article, no one date.
When did it appear, in 1985, together with the first Windows release ?
1981-1983 ?
"History" paragraph : what has Petzold said about 150 lines of code, still needs clarification. At least good that there is explicitly said, that he has told about Windows 1.0 SDK.

Alexander Ilyin 20:16, 4 July 2010 (UTC) —Preceding unsigned comment added by Cantregistermynick (talkcontribs)

Compiler support section[edit]

The compiler support section says that "For a long time, the Microsoft Visual Studio family of compilers and tools and Borland's compilers were the only tools that could provide this" (meaning the ability to handle Win32 headers etc.).

In my recollection, this is not true. Before Visual Studio came out, there was Microsoft C/C++, but also Zortech C/C++, Watcom C++ and Turbo C++. Zortech C++ became Symantec C++, was dropped by them, and then bought back by its original author and survives to this day as Digital Mars C++. Watcom was withdrawn from the market before satisfactorily implementing the ARM-level language. Turbo C++ became Borland C++. I owned all three. Watcom and Symantec supplied "memory extenders" which allowed Win32 programs to run on Win16 with Microsoft's redistridutable "win32s" shim DLL. I can't remember why I switched from Borland to Watcom but I think it was because Borland lacked 32-bit support.

I think you'll find the Zortech compiler was the first usable C++ on Win32/Win16, before even Microsoft had one.

Towards the end of this era COM appeared and assumed a certain binary vtable layout. At least Zortech tracked this change. I don't accept that COM is part of Win32, by the way. — Preceding unsigned comment added by (talk) 07:54, 7 September 2011 (UTC)

The MSFT-NSA conspiracy theory[edit]

The person that added the stuff about the NSA being able to 'access our computers' should really read: -- (talk) 14:02, 14 July 2013 (UTC)

Note #3 claims that Pascal was used to implement Windows[edit]

The Pascal calling convention was used because it saves on code size. That doesn't mean that the Pascal language was used. This fallacious claim should have a citation. — Preceding unsigned comment added by (talk) 18:44, 20 June 2015 (UTC)