Content deleted Content added
| (49 intermediate revisions by 26 users not shown) | |||
Line 1:
{{WikiProject banner shell|class=B|vital=yes|1=
{{WikiProject Microsoft Windows|importance=top|computing-importance=high}}
}}
{{afd-merged-from|Windows.pas|Windows.pas|01 December 2013}}
{{todo}}
== There is no such thing as Win64 ==
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.
[[User:Aidtopia|Aidtopia]] ([[User talk:Aidtopia|talk]]) 14:58, 13 April 2024 (UTC)
:The article says that "Both 32-bit and 64-bit versions of an application can be compiled from one codebase, although some older API functions have been deprecated, and some of the API functions that were deprecated in Win32 were removed." The disappearance of deprecated-in-Win32 functions might constitute an API change, although a citation for the claim that some APIs were removed should be provided. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 22:21, 13 April 2024 (UTC)
== API or rather ABI? ==
An A'''P'''I 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 A'''B'''I 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 set]]s!
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. [[User:ScotXW|ScotXW]] ([[User talk:ScotXW|talk]]) 12:02, 27 February 2014 (UTC)
==Internet Explorer Integration==
"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 [http://www.microsoft.com/windowsvista/features/foreveryone/ie7.mspx Microsoft's publications] <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:ItsProgrammable|ItsProgrammable]] ([[User talk:ItsProgrammable#top|talk]] • [[Special:Contributions/ItsProgrammable|contribs]]) 21:45, 25 November 2006 (UTC)</small>
== Windows API not property of Microsoft ==
"Windows API is basically considered not the property of Microsoft as is its implementation."
:What does this mean? <!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/217.158.203.79|217.158.203.79]] ([[User talk:217.158.203.79#top|talk]]) 12:47, 8 May 2003 (UTC)</small>
::Better now? -- [[User:Tim Starling|Tim Starling]] 01:43 26 May 2003 (UTC)
Line 20 ⟶ 43:
The history section here does not make much sense grammatically and needs expansion and cleanup. [[User:Dsav|Dsav]] 06:41, 28 Apr 2005 (UTC)
== Opinion, much? ==
"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." <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/173.9.45.237|173.9.45.237]] ([[User talk:173.9.45.237|talk]]) 20:33, 29 July 2009 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
== clean up? ==
Line 28 ⟶ 56:
:If nobody objects, I'm going to remove the cleanup tag in a couple of days. --[[User:Codemonkey|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. --[[User:Codemonkey|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. [[User:198.82.127.155|198.82.127.155]] 04:09, 28 August 2007 (UTC)
== To do ==
Line 34 ⟶ 64:
== .NET ==
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. <!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/84.35.41.43|84.35.41.43]] ([[User talk:84.35.41.43#top|talk]]) 20:30, 25 April 2006 (UTC)</small>
: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?
Line 62 ⟶ 92:
[[User:Ta bu shi da yu|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 <code><dd></code> and <code><dt></code> tags. I've moved the colons so that it looks a bit better.<span style="color:blue;font-weight:bold;font-family: Monotype Corsiva;"> [[User talk:Warrens|-/-]] [[User:Warrens|Warren]]</span> 07:10, 22 April 2007 (UTC)
== Is Win32 still a trademark? ==
If so, shouldn't this be mentioned in the article, since [[Win32]] redirects here? -andy [[User:194.138.39.140|194.138.39.140]] 16:28, 10 October 2007 (UTC)
== Where can we download it? ==
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.... <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/71.37.65.160|71.37.65.160]] ([[User talk:71.37.65.160|talk]]) 23:49, 27 December 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
: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) <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Oxinabox|Oxinabox]] ([[User talk:Oxinabox|talk]] • [[Special:Contributions/Oxinabox|contribs]]) </small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
: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]] ( [http://www.microsoft.com/downloads/info.aspx?na=47&p=1&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=a55b6b43-e24f-4ea3-a93e-40c0ec4f68e5&u=details.aspx%3ffamilyid%3dE6E1C3DF-A74F-4207-8586-711EBE331CDC%26displaylang%3den] ). You can use that with the [[Visual C++]] line of compilers and [[Microsoft Visual Studio]] IDE (including VC++ Express [http://www.microsoft.com/express/download/]). [http://blogs.msdn.com/windowssdk/archive/2008/02/22/using-visual-c-2008-express-with-the-windows-sdk-detailed-version.aspx 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. --[[User:Soumyasch|soum]] <sup>[[User talk:Soumyasch|talk]]</sup> 12:29, 7 May 2008 (UTC)
== API articles ==
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?
[[Special:Contributions/68.110.212.162|68.110.212.162]] ([[User talk:68.110.212.162|talk]]) 06:17, 18 February 2010 (UTC) not an ip -- not signed in
== No any date per whole article. ==
Per whole article, no one date.<br />
When did it appear, in 1985, together with the first Windows release ?<br />
1981-1983 ?<br />
"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.<br />
Alexander Ilyin 20:16, 4 July 2010 (UTC) <small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Cantregistermynick|Cantregistermynick]] ([[User talk:Cantregistermynick|talk]] • [[Special:Contributions/Cantregistermynick|contribs]]) </span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
== Compiler support section ==
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. <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/118.209.147.103|118.209.147.103]] ([[User talk:118.209.147.103|talk]]) 07:54, 7 September 2011 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
== The MSFT-NSA conspiracy theory ==
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
--[[Special:Contributions/212.121.112.33|212.121.112.33]] ([[User talk:212.121.112.33|talk]]) 14:02, 14 July 2013 (UTC)
== Note #3 claims that Pascal was used to implement Windows ==
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. <small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/50.159.105.93|50.159.105.93]] ([[User talk:50.159.105.93|talk]]) 18:44, 20 June 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
I'll bet Raymond Chen knows whether it is true. -steve <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar#top|talk]] • [[Special:Contributions/Stevebroshar|contribs]]) 11:56, 29 January 2024 (UTC)</small> <!--Autosigned by SineBot-->
== Infobox ==
I've added an infobox. I realize there are 2 things that may seem odd about it, so I thought I would explain:
# I've used a screenshot of ReactOS, as a screenshot of Windows would not be acceptable on Wikimedia Commons. ReactOS, the 3 Windows applications, and the novel Frankenstein can all be licensed under the GPL without issue.
# I saw a place in the software infobox for OS. Currently, I've placed Windows and OS/2 there as these were the only operating systems that were publicly claiming Windows compatibility. ReactOS, Wine, etc. strive for it, but do not have Microsoft's stamp of approval. OS/2 is debatable as it implemented the Windows API up to a certain version. ReactOS could possibly go there, if they explicitly claim to support the Windows API but I think they state something slightly different.
[[User:Rjjiii|Rjjiii]] ([[User talk:Rjjiii|talk]]) 05:45, 5 January 2023 (UTC)
== Function categories ==
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 [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 11:22, 29 January 2024 (UTC)
:Half measure: Added "notable" so that there is no need to be complete. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 13:14, 18 October 2024 (UTC)
== communication among different Windows applications ==
The paragraph with "communication among different Windows applications" seems to be about stuff that Windows API is not. Suggest: remove it. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 11:28, 29 January 2024 (UTC)
:I moved it to the section on related tech. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 13:13, 18 October 2024 (UTC)
== wrappers ==
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. Goes without saying. Adds no value. What is interesting about MFC WRT WinAPI?
Suggest: Either remove this section or don't say the other techs are wrappers -- just list them as other Microsoft Windows tech that the reader might want to peruse. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 11:54, 29 January 2024 (UTC)
:I updated that section (some time ago). No comments on the change or to my comment here. Hope it's OK. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 13:12, 18 October 2024 (UTC)
== History ==
The history section starts with ''The Windows API has always exposed a large part of the underlying structure of the Windows systems to programmers. This had the advantage of giving them much flexibility and power over their applications, but also creates great responsibility in how applications handle various low-level, sometimes tedious, operations that are associated with a graphical user interface.''
I don't know what do with that, but it's got issues.
* WinAPI exposes functionality; not structure
* WinAPI does not '''force''' developers to handle low-level stuff; it '''allows''' them to do low-level stuff
* How is GUI related to this?
[[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 13:25, 18 October 2024 (UTC)
:"WinAPI exposes functionality; not [the underlying structure of the Windows systems]" Given that a lot of the Win32 API was implemented in Windows 9x, the structure of which is a bit different from that of Windows NT, it definitely doesn't expose the "underlying structure" of Windows.
:"WinAPI does not '''force''' developers to handle low-level stuff; it '''allows''' them to do low-level stuff" Perhaps what they meant is that if you use ''only'' the Windows API, you have to do the low-level stuff yourself.
:"How is GUI related to this?" Perhaps they're saying that doing the low-level GUI stuff is more work than doing it elsewhere. But a citation for all of that would probably be called for here. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 00:15, 14 November 2024 (UTC)
== How are "Microsoft Windows library files" not shared libraries? ==
The article currently says:
{{blockquote|Programs can access API functionality via [[Shared library|shared-library]] technologies or via [[Microsoft Windows library files|system-file]] access.}}
[[Microsoft Windows library files]] says, right at the top of the page:
{{blockquote|The [[Microsoft Windows]] [[operating system]] and [[Microsoft Windows SDK]] support a collection of [[shared libraries]] that [[software]] can use to access the [[Windows API]]. This article provides an overview of the core libraries that are included with every modern Windows [[Installation (computer programs)|installation]], on top of which most Windows [[Application software|applications]] are built.}}
So the "system-files" (or just "system files - no need for the hyphen, at least in English) are, apparently, shared libraries.
In what way are they ''not'' shared libraries? If they are shared libraries, that statement is redundant. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 05:08, 2 February 2025 (UTC)
:I went ahead and cleaned this up, but next time feel free to clean it up directly. There's no need to open a discussion on such trivial matters. As an aside, thanks for all your contributions on all of these related topics. If you think it needs further refinement, be my guest. <span style="font-family:Verdana">{{u|[[User:Jamarr81|Jamarr81]]}}</span><sup>[[User talk:Jamarr81|🗣]][[Special:Contributions/Jamarr81|⸎]]</sup> 15:37, 20 July 2025 (UTC)
| |||