|
I agree you totally landed that one.
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
For some reason I THOUGHT today's totd would be about in denture Sir Vie s'tude ...
|
|
|
|
|
The solution is Twelve Monkeys
A monkey is slang for £500
£500 * 12 = £6000
An epic ( in my book )
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Why is
£500 known as a monkey?
American always curious about British(again American and not completely sure what to call this) slang
|
|
|
|
|
Same reason £25 is known as a pony. Although, 'pony' can also mean something less pleasant.
|
|
|
|
|
|
Cos it is 
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
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...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
