|
Triggered by Richard's post below.
What annoys me really is that they did not get the redirection of MSDN pages to MS Docs work properly. If you have a MSDN link for a wide version of an API function, it redirects to the ANSI version at MS Docs!
That happens even when already at Docs because all the links are MSDN links. Open for example GetFileVersionInfoExW function | Microsoft Docs[^] and follow links there like the one shown as GetFileVersionInfoSizeEx which links to https://msdn.microsoft.com/library/Aa969435(v=VS.85).aspx. But that is automatically redirected to Docs which is then GetFileVersionInfoSizeExA function | Microsoft Docs[^] instead of the expected GetFileVersionInfoSizeExW function | Microsoft Docs[^].
As a result, all existing answers here at CP and elsewhere containing MSDN links to API functions will now open the ANSI version when clicked. Another side effect is when inserting MSDN links now here at CP, the ANSI title from the Docs page is inserted while the link itself is still to MSDN.
|
|
|
|
|
I never liked the newer version of the documentation. Probably because I'm an old fart who likes to see documentation that is actually designed for programmers to read.
|
|
|
|
|
Same for me. But the MSDN online documentation is gone now.
The only advantage is that the links are now meaningful.
|
|
|
|
|
|
Hey, you can fix the links - once opened - by replaciny the trailing 'A' with a 'W'.
That wasn't possible (and necessary) with the MSDN numeric links.
|
|
|
|
|
But they could have done that in the first place ...
|
|
|
|
|
Quote: 06/11/2018
Well, if you will insist on reading documentation three months before it's published... 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Trying to answer a forum question I needed to use the Windows function GetFileVersionInfoA function | Microsoft Docs[^] - note the A suffix. So the documentation page at the bottom shows:
Library Mincore.lib
But when I built the program all the version related functions gave LNK2019 errors, unresolved external symbol. So I replaced Mincore.lib with Version.lib and it worked fine.
So is this a (not so) subtle attempt to withdraw support for non-Unicode builds?
|
|
|
|
|
Mincore.lib is also specified at GetFileVersionInfoW function | Microsoft Docs[^] and all other related APIs. The problem is that Mincore.lib is an "umbrella" library which contains (according to Windows 8 API Sets | Microsoft Docs[^]) only wrappers for the wide functions of the version APIs while wrappers for other API sections exist for the A and W versions.
Looks like they missed that when updating the documentation.
If they wanted to withdraw support for non Unicode, all MSDN redirections should go to the wide versions instead of the ANSI versions (see my rant above your post).
|
|
|
|
|
I was only half serious, it's obviously a documentation error.
|
|
|
|
|
It Looks like MS simply moved it from version.lib to minecore.lib. This maybe can help you:
Version Documentation Error?[^]
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
And, as usual, the responses from Microsoft demonstrate that their tech support are pretty useless.
|
|
|
|
|
Quote: And, as usual, the responses from Microsoft demonstrate that their tech support are pretty useless.
That is something a too hard judgment I think. MS does document the API pretty well, take into acount the amount of Information...
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Well that is a different issue; I was talking about the answers posted to questions in some of the Microsoft forums. I have always found (with a few exceptions that are less important) the information on MSDN to be useful and well presented.
|
|
|
|
|
Richard MacCutchan wrote: But when I built the program all the version related functions gave LNK2019 errors, unresolved external symbol.
Go back and #define WINVER and _WIN32_WINNT and recompile. The old version.lib is for legacy desktop applications. It sounds like you are either using an older compiler or targeting an older operating system < Windows 8.
It's basically a documentation issue. The documentation is incorrect if you are targeting older platforms. Much of the documentation will be moving to GitHub.
Best Wishes,
-David Delaune
|
|
|
|
|
No, none of those, it's a linker problem, not compiler. The issue has nothing to do with versions of Visual Studio or Windows (I'm using VS2017 on Windows 10), it's purely the fact that the A versions of those functions are not in Mincore.lib, despite the statement in the documentation.
|
|
|
|
|
Yeah,
The documentation is incorrect.
Best Wishes,
-David Delaune
|
|
|
|
|
You work for Microsoft, yes? If so, then I would take your word as truth here. Just saying...
|
|
|
|
|
Hi,
Don't take my word for it. Here is how you would check if the documentation was correct for GetFileVersionInfoA
1.) Open a CMD prompt and use dumpbin to check the export table of mincore.lib.
Here are the results:
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\um\x64>dumpbin /exports mincore.lib | findstr "GetFileVersion"
GetFileVersionInfoExW
GetFileVersionInfoSizeExW
GetFileVersionInfoSizeW
GetFileVersionInfoW
The ANSI version is not exported from mincore.lib as Richard MacCutchan describes and does indeed conflict with what the GetFileVersionInfoA function documentation states.
Best Wishes,
-David Delaune
|
|
|
|
|
Who still targets the ANSI versions nowadays anyway?
|
|
|
|
|
Anyone who still uses C or C++, where the default for character data is ASCII rather than Unicode.
|
|
|
|
|
I sometimes use a library that is wrapper for four others and it would be a PITA to make all of that work with Unicode. That's the only time I don't use Unicode these days and that is not very often.
One of these days I'll do it but it's pretty low on my priority list.
|
|
|
|
|
I realize it's still the default - but why should anyone not use the Unicode version? It's built-in, it's well understood, well-tested, and lets you target any number of languages.
|
|
|
|
|
dandy72 wrote: target any number of languages.
But this issue is purely about the C/C+ Windows libraries. And there are still many programs around that use ASCII. And judging by questions here, many new programmers are not being taught to use Unicode.
|
|
|
|
|
Richard MacCutchan wrote: But this issue is purely about the C/C+ Windows libraries
...which pretty much all support Unicode, so you might as well use it if there's any possibility you might need to internationalize your app...no?
Richard MacCutchan wrote: And judging by questions here, many new programmers are not being taught to use Unicode.
That's not an excuse for anyone else to fall back to purely ANSI APIs just to accommodate them.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
