Re: GLUT Stroke Font

On Jan 17, 2007, at 1:10 PM, Dennis Ruffer wrote:
> On Jan 17, 2007, at 12:11 PM, Charles Melice wrote:
>> In a preceding mail, after analysis of the problem, I had
>> concluded as
>> follows:
>>
>> <<I think It will not possible to use glut32.dll with SwiftForth.
>>
>> The executable GLUT consumer have to be a CONSOLE application: there
>> is a lot of "printf" in the code.
>>
>> Also, the executable have to be a multithreaded application.
>>
>> Inside GLUT.H, there is the next definition:
>>
>> /* GLUT callback calling convention for Win32. */
>> # define GLUTCALLBACK __cdecl
>>
>> So, the __cdecl convention is used. Not compatible with the original
>> CB: definition.>>
>
> Thanks for the feedback. I wondered why the talk about it here had
> just stopped
>
> Have you come up with any alternative?

On further analysis and reading an excellent article on the subject
at: http://www.codeproject.com/cpp/
calling_conventions_demystified.asp, I see that this is why I had to
declare all of the callbacks as taking 0 parameters. The caller
discards them and we simply return. I don't see any other difference
between __stdcall and __cdecl. Am I missing something?

Therefore, this doesn't appear to have anything to do with why my
window does not have stroke characters in it. I have traced through
each of the callbacks and I am confident that they are behaving
properly.

As far as printfs are concerned, I agree that there are a lot of them
in the glut-3.7.6 code. What I'm not so sure of is if/when they are
executed. I haven't seen any indication that they are executed
during the execution of the calls I am using, and I see many
indications that they printfs are inside TEST conditionals.

I'm not sure what you mean by multithreaded here, but I do remember
that there are some threading experiments in SwiftForth (see
fork.f). I am worried about the following statement in glut.h:

/* Win32 has an annoying issue where there are multiple C run-time
    libraries (CRTs). If the executable is linked with a different CRT
    from the GLUT DLL, the GLUT DLL will not share the same CRT static
    data seen by the executable. In particular, atexit callbacks
registered
    in the executable will not be called if GLUT calls its (different)
    exit routine). GLUT is typically built with the
    "/MD" option (the CRT with multithreading DLL support), but the
Visual
    C++ linker default is "/ML" (the single threaded CRT).

    One workaround to this issue is requiring users to always link with
    the same CRT as GLUT is compiled with. That requires users supply a
    non-standard option. GLUT 3.7 has its own built-in workaround where
    the executable's "exit" function pointer is covertly passed to GLUT.
    GLUT then calls the executable's exit function pointer to ensure
that
    any "atexit" calls registered by the application are called if GLUT
    needs to exit.

    Note that the __glut*WithExit routines should NEVER be called
directly.
    To avoid the atexit workaround, #define GLUT_DISABLE_ATEXIT_HACK. */

However, I haven't found a case yet where these calls help, or even
how to use them properly yet. This may end up being the problem and
I may really need to find out what this line is actually doing. Any
clues?

        extern _CRTIMP void __cdecl exit(int);

So, I don't think we've found root cause yet.

Still digging!
>>
>> Charles
>
> DaR

DaR

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and
bug reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Wed Jan 17 2007 - 14:00:59 PST