[comp.windows.ms.programmer] Turbo C++ and Win3 SDK

mikem@brahms.amd.com (Mike Moretti) (12/13/90)

I have been able to generate Windows3 applications using Turbo C++
and the SDK. I have noticed messages posted that this is not possible.
One reason mentioned the movement of segmetns. You can define a segment
to not be movable in your def file for the linker. I have not found this
to be a problem. The problems I have found were regarding the way
Turbo C++ mangles the names of procs/funcs, the start adress and the
data segment. I beleive that all of these problems have been overcome.
If Bordland provides a windows tool kit and it provides all the
same functionality (including 32-bit memory, etc) then it would be
the preferred choice. However, this is not available now. Below is
a description of how to use Turbo C++ with the SDK.

1. Create a stub.asm file with the following:

     extrn  __astart:far
     end    __astart

   Use masm to generate a stub.obj file.

2. Add the following to windows.h file:

#define _cdecl cdecl
#define _far far
#define _near near

3. In all of your files add the following at the top:

#ifdef __cplusplus
extern "C" {
#endif

4. At the end of all your files add:

#ifdef __cplusplus
}
#endif

5. In ALL functions/procedures add the _loadds directive. I.E.

int PASCAL _loadds WinMain(....

Note: ALL functions and procedures not just the ones called by windows.

6. Command line compile as follows:

tcc -I\windev\include -I\usr\tc\include -ml! -v -c  file.c

tcc -I\usr\tc\include -I\windev\include -ml! -v -Vs -c file.cpp

7. Your link response file should be as follows:

/CO /NOD /NOE /NOI file.obj stub.obj
file.exe,,
cl libw llibcew
file.def

8. In the above link statement the cl.lib file is the original
cl.lib file from Bordland MINUS FBRK and dos\crt0dat.asm.

9. When using sscanf and other library functions you may need to
create the temp storage these routines use. For example:
char ScanTodVector[256] will be needed for sscanf.


If anyone questions the validity of the above feel free to write
to me at mikem@brahms.amd.com

I have recently added a windows interface to an already existing
Turbo C++ program. It appears to run just fine.

davidds@microsoft.UUCP (David D'SOUZA) (12/24/90)

In article <1990Dec12.205410.16319@amd.com> mikem@brahms.amd.com (Mike Moretti) writes:
>I have been able to generate Windows3 applications using Turbo C++
>and the SDK. I have noticed messages posted that this is not possible.
>One reason mentioned the movement of segmetns. You can define a segment
>to not be movable in your def file for the linker. I have not found this
>
>5. In ALL functions/procedures add the _loadds directive. I.E.
>
>int PASCAL _loadds WinMain(....
>
>Note: ALL functions and procedures not just the ones called by windows.
>

Yes, this will work but beware... The application you just created is a
single  instance application!  If you run multiple instances of the
app, bizarre things will happen.  Remember, windows shares code
segments among multiple instances of applications.  _loadds causes 
(something similar to) the following prologue to be added to each function.

  mov ax,DGROUP
  mov ds,ax

DGROUP is patched at load time with your data segment.  Now if you load
 a second instance of your app, some code segments will be patched to
load your second ds (note patching is done only once at segment load
time).  If something is called from your first instance, ds changes to
something unexpected...

Also, it will only work in a protected mode environment unless you mark
you data segment as fixed.  This follows from my above statement that
at load time your ds segment is patched into the code.  If your ds
moves (as happend in real mode), you are hosed.  In protected mode,
ds is a selector which never changes so you win...

Another nice side effect of this trick is that since you are single
instance loadds, you won't have to do a MakeProcInstance on any of your
call back procedures.


BTW: This is a very good thing to use if you have a protected mode only
DLL since your dll will be much smaller without the windows prologue
hanging around every entry point... (Remember DLLs in Windows have only
one ds no matter how many apps use them so this works fine.)