This
level-5 vital article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Windows.pas was nominated for deletion. The discussion was closed on 01 December 2013 with a consensus to merge. Its contents were merged into Windows API. The original page is now a redirect to this page. For the contribution history and old versions of the redirected article, please see its history; for its talk page, see here. |
To-do list for Windows API:
|
There is not a distinct "major version" of the Windows API called Win64. 64-bit editions of Windows implement Win32. It's the same interface. Even the "Getting Ready for 64-bit Windows" article cited to support the notion that there is a Win64 is part of the Win32 documentation set (and it never says "Win64").
The reason Win32 is distinct from Win16 is that the API changed in incompatible ways. For starters, Win16 was the API for an OS that used cooperative multitasking, but Win32 used pre-emptive multitasking, so there were swaths of new functionality (e.g., synchronization objects, virtual memory), fundamental changes to the input and event models, reorganization of the fledgling Windows Registry, and the introduction of long file names. These changes had repercussions that required redesign to portions of the API. Some functions (notably many that dealt with window messages) had to be called with different parameters. To ease porting from Win16 to Win32, message-crackers and the Win32s overlay were offered to paper over some of the breaking changes. But most program required some changes to work with the new API.
For 64-bit systems, the API did not need to change in incompatible ways. The _ABI_ is different (pointer sizes, calling conventions, etc.). Details of the implementations may be different. But the _API_ is the same. The same functions accept the same parameters and return values have the same meaning.
If a Windows program cannot be compiled for both 32- and 64-bit systems, it's due to a non-portable assumption baked into the code about pointer sizes or ranges of representable values—it's not because of an incompatible difference in the Windows API. Aidtopia ( talk) 14:58, 13 April 2024 (UTC)
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 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 — Preceding unsigned comment added by ItsProgrammable ( talk • contribs) 21:45, 25 November 2006 (UTC)
"Windows API is basically considered not the property of Microsoft as is its implementation."
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)
"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 173.9.45.237 ( talk) 20:33, 29 July 2009 (UTC)
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'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. — Preceding unsigned comment added by 84.35.41.43 ( talk) 20:30, 25 April 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. ;) -- 213.169.107.51 09:10, 10 August 2006 (UTC)
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)
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)
http://bugzilla.wikimedia.org/show_bug.cgi?id=9660
Ta bu shi da yu 06:52, 22 April 2007 (UTC)
<dd>
and <dt>
tags. I've moved the colons so that it looks a bit better.
-/-
Warren 07:10, 22 April 2007 (UTC)If so, shouldn't this be mentioned in the article, since Win32 redirects here? -andy 194.138.39.140 16:28, 10 October 2007 (UTC)
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
71.37.65.160 (
talk) 23:49, 27 December 2007 (UTC)
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? 68.110.212.162 ( talk) 06:17, 18 February 2010 (UTC) not an ip -- not signed in
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 ( talk • contribs)
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 118.209.147.103 ( talk) 07:54, 7 September 2011 (UTC)
The person that added the stuff about the NSA being able to 'access our computers' should really read: http://www.dailykos.com/story/2013/06/15/1216509/-The-MSFT-NSA-conspiracy-theory -- 212.121.112.33 ( talk) 14:02, 14 July 2013 (UTC)
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 50.159.105.93 ( talk) 18:44, 20 June 2015 (UTC)
I'll bet Raymond Chen knows whether it is true. -steve — Preceding unsigned comment added by Stevebroshar ( talk • contribs) 11:56, 29 January 2024 (UTC)
I've added an infobox. I realize there are 2 things that may seem odd about it, so I thought I would explain:
Rjjiii ( talk) 05:45, 5 January 2023 (UTC)
The overview section currently lists categories of functions in the API, but I have two concerns about that. 1) Does not seem a good purpose for wikipedia to cover all the technical details of an API. Let the Microsoft docs cover the technical details and let this article cover higher-level concepts -- mostly what's _not_ covered by Microsoft. 2) There's a note saying the list is out-of-date. What would one update to? the latest version? This article is about _all_ versions; not just the latest. Could list the categories for _each_ version, but that's too hard to do and to get right.
Suggestion: KISS -- remove the list of categories Stevebroshar ( talk) 11:22, 29 January 2024 (UTC)
The paragraph with "communication among different Windows applications" seems to be about stuff that Windows API is not. Suggest: remove it. Stevebroshar ( talk) 11:28, 29 January 2024 (UTC)
Most of the tech listed as wrappers are not what I'd call a wrapper. IMO a wrapper exposes roughly the same capabilities as the wrapped tech -- just in a different form (interface). Just because one tech uses another tech, does not make it a wrapper. Consuming is not wrapping.
Wrapping requires design intent to replace all consumption need for the underlying tech. For example, MFC and ATL are not intended to replace all consumer need for Windows API.
Taking a step back: What is the point of this section? For example, it says MFC uses Windows API. ok. Everything built for Windows uses Windows API. What is interesting about MFC doing that? Goes without saying. Adds no value.
Suggest: Either remove this section or at least that these other techs are wrappers -- just list them as other Microsoft Windows tech that the reader might want to peruse. Stevebroshar ( talk) 11:54, 29 January 2024 (UTC)
This
level-5 vital article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Windows.pas was nominated for deletion. The discussion was closed on 01 December 2013 with a consensus to merge. Its contents were merged into Windows API. The original page is now a redirect to this page. For the contribution history and old versions of the redirected article, please see its history; for its talk page, see here. |
To-do list for Windows API:
|
There is not a distinct "major version" of the Windows API called Win64. 64-bit editions of Windows implement Win32. It's the same interface. Even the "Getting Ready for 64-bit Windows" article cited to support the notion that there is a Win64 is part of the Win32 documentation set (and it never says "Win64").
The reason Win32 is distinct from Win16 is that the API changed in incompatible ways. For starters, Win16 was the API for an OS that used cooperative multitasking, but Win32 used pre-emptive multitasking, so there were swaths of new functionality (e.g., synchronization objects, virtual memory), fundamental changes to the input and event models, reorganization of the fledgling Windows Registry, and the introduction of long file names. These changes had repercussions that required redesign to portions of the API. Some functions (notably many that dealt with window messages) had to be called with different parameters. To ease porting from Win16 to Win32, message-crackers and the Win32s overlay were offered to paper over some of the breaking changes. But most program required some changes to work with the new API.
For 64-bit systems, the API did not need to change in incompatible ways. The _ABI_ is different (pointer sizes, calling conventions, etc.). Details of the implementations may be different. But the _API_ is the same. The same functions accept the same parameters and return values have the same meaning.
If a Windows program cannot be compiled for both 32- and 64-bit systems, it's due to a non-portable assumption baked into the code about pointer sizes or ranges of representable values—it's not because of an incompatible difference in the Windows API. Aidtopia ( talk) 14:58, 13 April 2024 (UTC)
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 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 — Preceding unsigned comment added by ItsProgrammable ( talk • contribs) 21:45, 25 November 2006 (UTC)
"Windows API is basically considered not the property of Microsoft as is its implementation."
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)
"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 173.9.45.237 ( talk) 20:33, 29 July 2009 (UTC)
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'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. — Preceding unsigned comment added by 84.35.41.43 ( talk) 20:30, 25 April 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. ;) -- 213.169.107.51 09:10, 10 August 2006 (UTC)
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)
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)
http://bugzilla.wikimedia.org/show_bug.cgi?id=9660
Ta bu shi da yu 06:52, 22 April 2007 (UTC)
<dd>
and <dt>
tags. I've moved the colons so that it looks a bit better.
-/-
Warren 07:10, 22 April 2007 (UTC)If so, shouldn't this be mentioned in the article, since Win32 redirects here? -andy 194.138.39.140 16:28, 10 October 2007 (UTC)
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
71.37.65.160 (
talk) 23:49, 27 December 2007 (UTC)
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? 68.110.212.162 ( talk) 06:17, 18 February 2010 (UTC) not an ip -- not signed in
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 ( talk • contribs)
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 118.209.147.103 ( talk) 07:54, 7 September 2011 (UTC)
The person that added the stuff about the NSA being able to 'access our computers' should really read: http://www.dailykos.com/story/2013/06/15/1216509/-The-MSFT-NSA-conspiracy-theory -- 212.121.112.33 ( talk) 14:02, 14 July 2013 (UTC)
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 50.159.105.93 ( talk) 18:44, 20 June 2015 (UTC)
I'll bet Raymond Chen knows whether it is true. -steve — Preceding unsigned comment added by Stevebroshar ( talk • contribs) 11:56, 29 January 2024 (UTC)
I've added an infobox. I realize there are 2 things that may seem odd about it, so I thought I would explain:
Rjjiii ( talk) 05:45, 5 January 2023 (UTC)
The overview section currently lists categories of functions in the API, but I have two concerns about that. 1) Does not seem a good purpose for wikipedia to cover all the technical details of an API. Let the Microsoft docs cover the technical details and let this article cover higher-level concepts -- mostly what's _not_ covered by Microsoft. 2) There's a note saying the list is out-of-date. What would one update to? the latest version? This article is about _all_ versions; not just the latest. Could list the categories for _each_ version, but that's too hard to do and to get right.
Suggestion: KISS -- remove the list of categories Stevebroshar ( talk) 11:22, 29 January 2024 (UTC)
The paragraph with "communication among different Windows applications" seems to be about stuff that Windows API is not. Suggest: remove it. Stevebroshar ( talk) 11:28, 29 January 2024 (UTC)
Most of the tech listed as wrappers are not what I'd call a wrapper. IMO a wrapper exposes roughly the same capabilities as the wrapped tech -- just in a different form (interface). Just because one tech uses another tech, does not make it a wrapper. Consuming is not wrapping.
Wrapping requires design intent to replace all consumption need for the underlying tech. For example, MFC and ATL are not intended to replace all consumer need for Windows API.
Taking a step back: What is the point of this section? For example, it says MFC uses Windows API. ok. Everything built for Windows uses Windows API. What is interesting about MFC doing that? Goes without saying. Adds no value.
Suggest: Either remove this section or at least that these other techs are wrappers -- just list them as other Microsoft Windows tech that the reader might want to peruse. Stevebroshar ( talk) 11:54, 29 January 2024 (UTC)