🚀 go-pugleaf

"Robert F. Monroe" <Robert@hever.demon.co.uk> wrote:

>In article: <4gfb10$21p@solutions.solon.com>  mcv@pi.net (Miguel Carrasquer Vidal) writes:

>> This is what Microsoft's ``Knowledge Base'' has to say about it:
>	[snip]
>> The sscanf(), fprintf(), and scanf() functions are not available for
>> Windows DLLs.

>A brief 10 minute experiment proved to me that this is simply
>not true. I used VC++ 2.0. No problem.

>int __declspec(dllexport) TestPrintfAndScanf(void)

But that's Win32!

>PS: I don't mean to sound like I am defending Microsoft, but it 
>does not appear that they have done anything "stupid" or 
>"insane". In this case, it looks like their worst offense is 
>offering misleading documentation. Anyone who is genuinely 
>interested in using these functions in a DLL should consider
>testing them. You might be surprised at the results.

I don't mean to sound like I'm defending Microsoft either,
but their documentation is certainly not misleading.
I'll quote the article's header again:

>PSS ID Number: Q76684
>Article last modified on 08-02-1995
> 
>3.00 3.10
> 
>WINDOWS
> 
>----------------------------------------------------------------------
>The information in this article applies to:
> 
> - Microsoft Windows Software Development Kit (SDK) for Windows
>   versions 3.0 and 3.1
             ^^^     ^^^

The documentation is correct.

What's at fault is the implementation of the 16-bit DLL runtime
library (at least for earlier, pre "Visual", versions of Microsoft
C/C++).  



==
Miguel Carrasquer Vidal                     ~ ~
Amsterdam                   _____________  ~ ~
mcv@pi.net                 |_____________|||

========================== Ce .sig n'est pas une .cig