Re: Problems running on Win95

On 19 Aug 1996, Kim Liu wrote:

> I might have found out the reason behind the problem I posted earlier. 
> Basically whenever you build an application under Win32, you have a choice of 
> either a MS Windows application or a Console application. From the default 
> setting in the distribution, both the Library and LineMode browser are set up 
> as MS Windows applications (by defining the symbol _WINDOWS). That's why they 
> work fine together. However, when I tried to build libapp_4 and ComLine, I 
> chose to build them as a Console application. This is a natural choice 'cos 
> they can simply interact with the user by standard I/O. The problem is there 
> are some modules in the Library (HTUtil and HTAlert?) that got compiled 
> differently under different CONSOLE vs MS Windows set up. So what I have to do 
> is to recompile the Library with the _CONSOLE symbol (besides using the DLL C 
> runtime library). This makes the ComLine works but messes up LineMode. Does 
> anyone know what exactly is going on here? 
> -Kim 

Off the top of my head, I'd say that the only modules that change from 
_CONSOLE to _WINDOWS are the HTEvntrg and HTString modules. HTEvntrg has 
a vast difference because of the different input models between the two 
builds. HTString just needs to know if the logging output can use 
fprintf. One possible way to handle this is to build different dlls for 
each model. For instance, wwwutils.dll and wwwutilsW.dll to get HTString 
and wwwapp.dll and wwwappW.dll to get HTEvntrg.

Alternatively, you could patch HTString with a function this:

PRIVATE BOOL useVfprintf = TRUE;

PUBLIC void HTTrace_setFPrint(BOOL now)
    useVfprintf = now;

and fix the THTrace function to return after calling the TraceCallback:

PUBLIC int HTTrace(const char * fmt, ...)
    va_list pArgs;
    va_start(pArgs, fmt);
    if (PHTTraceCallback)
!	return (*PHTTraceCallback)(fmt, pArgs);
    return (0);
    return (vfprintf(stderr, fmt, pArgs));

Now, compile the library with _CONSOLE defined and make sure that any 
Windows apps set the HTTraceCallback to make sure vfprintf is never be 

Since there are no calls from wwwapp.dll to HTEvntrg, that mdoule can be 
superceeded by linking the app to a special windowed version, HTEvntrgW.
This can be done by including HTEvntrg in LineMode. MSVC will default to 
putting the .obj in the LineMode object directory so you won't have to 
worry about it obliterating the library (_CONSOLE) version.

To summarize:
1 patch HTString.c
2 build library with _CONSOLE defined
3 link all CONSOLE apps to the library normally
4 include HTEvntrg in the WINDOWS apps
5 write me back to tell me what I missed

as Henrik says, have fun,