|
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.
|
|
|
|
|
dandy72 wrote: you might need to internationalize your app
Who would want to do that? Mercans? 
But seriously. I am not defending either stance, merely saying what is the reality. Bjorn had the chance when he created C++ to make Unicode the default, but since he didn't it is still a PITA to do it.
|
|
|
|
|
Richard MacCutchan wrote: Bjorn had the chance when he created C++ to make Unicode the default, but since he didn't it is still a PITA to do it.
Is it?
I haven't done C++ in a dozen years (never looked back after C#), and I remember that the Windows SDK had a pretty decent set of macros that invoked either the A or W variants of pretty much all APIs based on compiler flags. Once I had settled into a routine of writing all my code "following that style", it was pretty much a no-brainer.
Or so I recall.  OTOH it's not like I have any reason to be trying to paint a prettier picture of C++ than what it was actually like for me.
|
|
|
|
|
That is all very true, but I was talking about the use of character constants:
TCHAR* psomething = TEXT("some text");
WCHAR* psomethingElse = L"sometext";
as opposed to
char text = "some text";
and even wstring is the same, and try using wcout to print some Unicode characters.
|
|
|
|
|
Agreed...took me a while to get used to it, but once you've settled into the pattern, it became second nature to me. But making the transition was painful.
My surprise was that this isn't what newcomers are getting exposed to from the get-go in this day and age, so they don't have to "unlearn everything they thought they already knew about string manipulation".
|
|
|
|
|
|
Hilarious! Loved Jamie Olivers christmas turkey as well!
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
