But DO C hackers code concisely? 
Author Message
 But DO C hackers code concisely?

I did some testing with VC++ 2.0 and, as it turns out, all of
the printf and scanf functions work perfectly in a DLL. No
problem at all. I even tried calling (from a console program) a
DLL function that contained a call to printf and scanf with no
problems at all. So, I was mistaken when I said that scanf does
not work in a DLL. I should have checked before speaking.

        Bob.

[Approving this simply because it directly contradicts the other posting
 in this batch quoting Microsoft's explanation. -mod]



Sun, 09 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?



:>

:>
:> >What conceivable use could there be for either printf or scanf in a
:> >Windows DLL?
:>
:> The sprintf and sscanf variations do come in handy even when the I/O
:> capabilities doesn't match the expectations of stdio.h - so does
:> fprintf and fscanf in Windows - there is no 'terminal' concept but
:> there *are* disk files.
:
:sprintf and sscanf CAN be used in a DLL. The message that I was commenting
:on indicated that Microsoft was "stupid" for not allowing printf and scanf
:in DLLs. Again, there would be no use for printf and scanf in a DLL so I don't
:consider it particularly stupid to make them unavailable. As you say, there
:could be all sorts of uses for sprintf and sscanf, but they are not the same
:as printf and scanf.

There is one good reason to allow sprintf/sscanf bot not printf/scanf in
a DLL:  printf/scanf need to malloc() a memory buffer.  sprintf/sscanf
need not do this, since they are given a memory buffer when called.

--
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN



Sun, 09 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?
I promise that I will drop it after this one (Honest!):


Quote:
> 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.

Here is the source for the DLL testing printf, scanf, sprintf
and sscanf:

#include <stdio.h>

int __declspec(dllexport) TestPrintfAndScanf(void)
{

    char name[40], buff[80];
    int age;

    printf("Enter you surname and age: ");
    scanf("%s %d", name, &age);
    sprintf(buff, "Hello %s, are you really %d?", name, age);
    printf("%s\n", buff);
    sprintf(buff, "%s %d", name, age);
    *name = '\0'; age = 0;
    sscanf(buff, "%s %d", name, &age);
    sprintf(buff, "Hello again %s, are you still %d?",
                name, age);    
    printf("%s\n", buff);
    return 0;

Quote:
}

Here is the source for the console application:

extern int TestPrintfAndScanf(void);

int main() {return TestPrintfAndScanf();}

They both compile and link with no warnings, no errors and the
behavior at runtime is just what I would expect. Works fine.

Quote:
> There are two factors that cause these functions to be incompatible:

> 1. These functions rely on near pointers.  
> 2. These functions expect SS == DS.

> Because neither of these conditions is true when a function in a DLL
> uses data from an application, these functions are not available.

Item 1: I used a 32-bit version of the compiler, so there is no
such thing as near pointer.
Item 2: In my DLL, SS does equal DS.

All of these functions seem to work perfectly in a DLL (at least
with VC++ 2.0). I think that it is the MS documentation that is
flawed, not the compiler or libraries.

I will drop it now,
        Bob.

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.



Mon, 10 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:

> I promise that I will drop it after this one (Honest!):

> 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.

[snip]

Quote:
> Here is the source for the console application:

[snip]

Quote:
> Item 1: I used a 32-bit version of the compiler, so there is no
> such thing as near pointer.
> Item 2: In my DLL, SS does equal DS.
> All of these functions seem to work perfectly in a DLL (at least
> with VC++ 2.0). I think that it is the MS documentation that is
> flawed, not the compiler or libraries.

[snip]

Item 1 is the critical part.  In MSVC 1.5x and earlier (and therefore
in any Win16 DLL), the ...printf/...scanf family is not available.
Console applications don't even exist in Win16 (AKA Win 3.1x).  Yes,
Win32 is less brain dead than Win16 was, but most people still only
know Win16.  (I happen to know both due to my current job.)

Just a Thought,
Jim Trigg

[Approved solely because it answers the question of whether or not printf
 and scanf are available in DLL's, which has been answered both ways. -mod]



Mon, 10 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:

>> 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!

Quote:
>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:

Quote:
>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                   _____________  ~ ~

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



Thu, 13 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:

>There is one good reason to allow sprintf/sscanf bot not printf/scanf in
>a DLL:  printf/scanf need to malloc() a memory buffer.  sprintf/sscanf
>need not do this, since they are given a memory buffer when called.

Huh?  Why is this a "good reason"?  Are you saying that malloc()
cannot be used in a DLL either?  (I've never used DLL's, but
it's beginning to sound to me that any claim that you can use
"C" with them could be considered fraudulent.)

Also, even if the reason for not having printf/scanf makes some sense
(nowhere for the input to come from / output to go to), there
surely would be a need for fprintf/fscanf, which surely require
malloc() if printf/scanf do.

I am not impressed by any of the arguments others have made pertaining
to near vs. far pointers.  Any sensible compiler could (and should)
take care of that whenever #include <stdio.h> is present.

Cheers,
Stan.
--



Fri, 14 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:

>These samples _are_ pretty wordy, no doubt.  As to the fact that both
>can be adequately replaced with sprintf() calls can probably be
>explained as: 1. ignorance; or 2. efficiency by writing a special-
>purpose function instead of going through a general-purpose function.
>How valid the latter argument is depends on the application, of
>course.

But the code is not efficient!  A binary->hexadecimal routine can be written
in less space than either example, then used in both.  The examples ALREADY
call a function, but they call the wrong one, and then waste a lot of time
patching up the result.  The author is supposed to be an *expert*.

Quote:
>>Line 1:  two superfluous pairs of parentheses, could be
>>    ltoa(lBufIndex*16, buf, 16);
>I must make a specific comment here, though: While the original was
>unquestionably paren-happy, don't discount code where extra parens
>really _do_ add to clarity.

I don't discount it, any more than I discount the importance of white
space.  Adding too much of either all the time, however, helps no-one.
Again, the point is that this guy is *supposed* to be an expert.

Quote:
>However, I do appreciate C's compactness of expression on occasion.

Let me say it once again:  compactness of EXPRESSIONS is not at all the
same as compactness of PROGRAMS.  A programmer who writes 20 ten-character
lines has written a less compact PROGRAM than a programmer who writes 10
twenty-character lines, even though every EXPRESSION in the first program
is more compact than every expression in the second.  I think that was my
main point, really.

Quote:
>String parsing routines are very often this way.  (Isn't it ironic
>that the code snippets you showed _were_ string parsing routines?)

It would be, except that they were actually string _generation_ code
that wouldn't have been doing _any_ parsing if it had been done right.

--
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.



Fri, 14 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:
> >----------------------------------------------------------------------
> >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.

Sorry about that. It was pointed out to me in a private e-mail.
Actually the original posting that I was refering to made the
unqualified statement that some printf/scanf functions do not
work in DLLs. If you go back a couple of major releases, then
I can see where it is true. Right now, I have bigger complaints
about MS than the limitations of previous versions of their
compilers.

Again, sorry about the error but my eyes really did glaze right
over that note.

        Bob.



Fri, 14 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:

>> Item 1: I used a 32-bit version of the compiler, so there is no
>> such thing as near pointer.

> Item 1 is the critical part.  In MSVC 1.5x and earlier

Except that he phrased it wrong: in the 32-bit versions of MSVC, there
are ONLY near pointers - which of course are 32 bits bit.  What's missing
are far pointers, which would be 48 bits big....

--
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN



Fri, 14 Aug 1998 03:00:00 GMT  
 But DO C hackers code concisely?

Quote:

>Item 1 is the critical part.  In MSVC 1.5x and earlier (and therefore
>in any Win16 DLL), the ...printf/...scanf family is not available.
>Console applications don't even exist in Win16 (AKA Win 3.1x).  Yes,
>Win32 is less brain dead than Win16 was, but most people still only
>know Win16.  (I happen to know both due to my current job.)

    ugh.  as you pointed out before making your point at the end,
    this is NOT operating system specific, but compiler specific.

    for example, the Windows compiler that I use supports
    sscanf() perfectly fine in a DLL (anything less is not
    only uncivilized, but ridiculous).  sprintf() works too.
    using the wsprintf() version is not the same because it
    doesn't have the same capabilities as what the
    Standard functions do (no floating point conversions).

    heck, I can use the other printf/scanf family members in a
    Windows 16 bit application, but not in a DLL.   "hello world"
    works just fine.

    ANYWAY, i just wanted to point out that not only has this
    discussion strayed FAR from the normal clcm scope, but that
    it was based upon a statement that is either 1) erroneous, or
    2) is specific to one compiler vendor's ridiculous C implmentation.
    I don't believe the second option, but i don't have any sort
    of counter-proof.

[It has rather strayed.  I'll probably start squelching discussion on this
 RSN. -mod]

 --xmsb



Fri, 14 Aug 1998 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software