POLINK: fatal error: Missing full MS-DOS header in stub file: 'HELLO.EXE'.

[Bastiaan]

Pelles C is a great compiler (the best probably) and I hope this topic will become useful for users of Pelles C. I am trying to implement my own DOS-STUB, so that people who would run my program (compiled with PellesC) in DOS would not see the standard message "This program cannot be run in DOS mode", but instead a different message. As a test I made two simple "Hello world!" programs: one that is compiled with Pelles C and displays a MessageBox and the other a program that was compiled with the antique TurboC version 2.01 and runs in DOS mode. For information, I attached the PellesC project (zipped), the C-file Hello.c to be compiled with TurboC version 2.01 and the executable Hello.exe that is obtained when Hello.c is compiled with TurboC version 2.01. After I changed the linkflags from

 -subsystem:windows -machine:x86  kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib

into:

 -subsystem:windows -machine:x86  -stub:HELLO.exe  kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib

(so I just added "-stub:HELLO.exe " to the linkflags.) rebuilding all files did not succeed and the following message is displayed by PellesC:

POLINK: fatal error: Missing full MS-DOS header in stub file: 'HELLO.EXE'.

I HOPE PELLESC COULD BE MODIFIED A BIT SO THAT IT WOULD BE POSSIBLE TO IMPLEMENT DOS-STUBS CREATED BY TURBOC VERSION 2.01 !! (Additional Remark: It is possible to use an executable that was generated with PellesC as a "DOS-stub", using a PE-viewer I verified that this is done correctly as far as I could see. But of course it makes no sense to do this as the "DOS-stub" has its own nested DOS-stub, which would probably be exectuted when the program is run in DOS mode).

I hope the above will lead to an interesting discussion!

Regards,
Bastiaan

[Pelle]

Not possible, as it seems. The linker must set the offset to the PE signature (and image), which is a field defined in the MS-DOS header for a NE (new executable) file (OS/2, Win16), but not in the 'plain' MS-DOS header. Writing this offset in an old DOS exe will destroy some other data (following the header), and rebuilding the DOS exe into a NE exe is not really an option. The help file is currently a bit misleading, so I will correct that, but otherwise I can't do very much...

Linking with Microsoft LINK, I get 'warning LNK4060: stub file missing full MS-DOS header; rebuild stub with /KNOWEAS 16-bit LINK option'.

The Visual Studio 2005 help file says the following about this warning 'The MS-DOS application specified with the /STUB option does not have a full 40-byte header. The stub program may not run as expected. To rebuild the 16-bit stub with a full 40-byte header, use the undocumented /KNOWEAS option with the 16-bit LINK version 5.5x or higher.'

Maybe this helps...

[severach]

The only way I could find to produce a POLINK stub compatible dos program was to compile with Microsoft C 7 for DOS after updating the linker. I was shocked to find that the other DOS compilers dropped the ball on this one.

[Bastiaan]

Thank you Pelle and also Severach for replying.

I haven't tested microsoft LINK yet in this respect. It seems that this program is difficult to obtain and even if I would get it, I probably would need some help on how to set all the possible flags and options. This because I do not have a lot of experience using a LINKER, and that is partly due to PellesC (which makes us lazy by always doing all the complicated work correctly...).

I think it would be nice if everything could be done with PellesC (and POLINK) so no additional linker would be required.
Also the comments made by Severach that many DOS-compilers fail to produce an executable compatible with POLINK strengthen this view. By the way, I have briefly searched for Microsoft C 7 for DOS but did not find it anywhere...

One of the comments by Pelle ("Writing this offset in an old DOS exe will destroy some other data ...") made me thinking ... It seems that the problem to be solved is how to deal with the difference between the "new-style" DOS-header (in a New Executable) and the "old-style" DOS-header (in a plain dos executable) and how to create extra "space" in the executable. I believe I have discovered a not too complicated way of doing this with PellesC only!

Step-by-step, it goes as follows:

(1) create a file of the same size as (or larger than) the "old-style" dos executable that one wants to use as a stub-file, but filled with mainly zero's (but at some places the right data just to get it accepted by POLINK as a "valid "stub file). I created a PellesC project, CreateDummyStubMyPr, that can do this (see attachment). The resulting file is "aap.exe" (this is not a real executable, it only is able to "trick" POLINK in believing it is an exe file!)

(2) In the PellesC project where one wants to implement the "old style" dos executable as a stub, first implement "aap.exe" as a stub, by adding -stub:aap.exe to the LINKFLAGS (in project-project options -> macros). As an example, I attached the PellesC project WindowsDtubMyPr. Do not forget to put the file aap.exe that was created during step (1) in the right folder so it can be found by PellesC during compiling WindowsDtubMyPr!

(3) in the resulting executable (WindowsDtubMyPr.exe) from compiling the project mentioned in step (2), the "real" DOS-stub is inserted right AFTER the new-style DOS header (will be done automatically, see below).

(4) some final changes need to be implemented (automatically, see below) in the executable to form a hybrid header of old-style and new-style. This is now possible as we start with a new-style header, which is larger than an old-style header so no extra "space" is required anymore!

I created a PellesC program, CreateStubMyPr, that can do step (3) and (4) automatically, (see attachment). It can be seen from this program that the required changes during step (4) are minimal!

The executable that is created during step (4) is a valid windows executable. When run in DOS mode it will execute the intended DOS-stub.

I have not yet verified the above procedure for more complex DOS-stubs, so I am not yet sure if the scheme will work in general or if there are any limitations for the possible DOS-stubs that could be used.

Also I haven't performed extensive BUG testing of the attached programs or extensive error-checking.
Perhaps I will later post some improved versions. So please do not apply the attached programs without taking care!


Final remark/question: I believe that the here given scheme implies that, potentially, PellesC could be adapted so that DOS-executables (generated with for example the antique turbo-c version 2.01 ) could be used as stubs.  Have I overlooked anything?

I am interested to see any reactions to the above!

Regards,
Bastiaan

[Stefan Pendl]

I haven't tested microsoft LINK yet in this respect. It seems that this program is difficult to obtain and even if I would get it, I probably would need some help on how to set all the possible flags and options. This because I do not have a lot of experience using a LINKER, and that is partly due to PellesC (which makes us lazy by always doing all the complicated work correctly...).

LINK.exe is included in the Windows Platform SDK and the .NET Framework SDK.

To get the options just use the good old link /?

[Vortex]

link.exe comes also with the Masm32 package :

http://www.masm32.com/masmdl.htm

[Bastiaan]

Okay, I warned before that I have not a lot of experience with link.exe. Here a summary of my attempts.

GENERAL OBJECTIVE: I am trying to LINK the object file WindowsStub.obj and the DOS-executable HELLO.exe to form a windows executable WindowsStub.exe that has HELLO.exe as a DOS-STUB.

FIRST ATTEMPT TO REACH THE GENERAL OBJECTIVE (this attampt badly failed and is given for the sake of completion only, it is probably best the reader directly goes to the second attempt given below):

I tried to see if I could get link.exe to do something "simple": to create WindowsStub.exe from WindowsStub.obj.

In order to do this I first tried to use link.exe (obtained from the MASM32 package). I put the file link.exe in the same folder as the file WindowsStub.obj and went with the command prompt to that folder and issued the command

link WindowsStub.obj

I then got the following error message:

link.exe - Unable To Locate Component
This application has failed to start because mspdb50.dll was not found.
Re-installing this application may fix this problem.

So then, -following this suggestion-, I copied the file mspdb50.dll from the MASM32 package into the folder of the file WindowsStub.obj and again issued the following command on the command prompt:

link WindowsStub.obj

The following error massage appeared however:

LINK : fatal error LNK1104: cannot open file "crt.lib"

So I found the file crt.lib in the PellesC/Lib folder and copied that file also into the folder of the object file WindowsStub.obj. Again issuing the command

link WindowsStub.obj

now yielded the following error message:

LINK : fatal error LNK1104: cannot open file "kernel32.lib"

copying the file kernel32.lib from the PellesC package into my folder and issuing the command

link WindowsStub.obj

now resulted in:

WindowsStub.obj : error LNK2001: unresolved external symbol __imp__MessageBoxA@16
WindowsStub.exe : fatal error LNK1120: 1 unresolved externals

At this point I decided to give up because the above approach does not seem to work! Actually, the use of PellesC in the second attempt below sheds some light on the correct use of flags and options with link.exe.

SECOND ATTEMPT TO REACH THE GENERAL OBJECTIVE:
(=To let PellesC do all the dirty work!)
I temporarily deleted the file polink.exe from the folder PellesC/bin
I put the file link.exe in this folder and renamed it into polink.exe.
In PellesC I changed the LINKFLAGS (accessed via Project->Project Options->MACROS) into:

 -subsystem:windows -machine:x86 -stub:"C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\HELLO.exe" kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib

Now I tried to build WindowsStub.exe using PellesC.
The following error message appeared:

polink.exe - Unable To Locate Component
This application has failed to start because mspdb50.dll was not found.
Re-installing this application may fix this problem.

(almost literally the same as one of the previous error messages)

So I next put the file mspdb50.dll from the MASM32 package) into PellesC/bin. Trying to build WindowsStub.exe using PellesC resulted in the following messages from PellesC:

Building WindowsStubMyPr.exe.
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\HELLO.exe : warning LNK4060: stub file missing full MS-DOS header; rebuild stub with /KNOWEAS 16-bit LINK option
Done.

This was good to see as it reproduces what Pelle already observed!

Next, I tried to use the /KNOWEAS option, but it was not recognized by link.exe. Then, I noticed that the linker version is 5.12.8078 so not 5.5x as Pelle suggested. So that's probably why the /KNOWEAS option was not recognized...

So here I decided to give up for the moment and post the above experiences to the forum in the hope someone might come up with an easy solution. Perhaps I could have done more by trying to get the 16-bit LINK version 5.5x or higher, but I have the following doubts about it:

• the error message by link.exe says that the stub needs to be rebuilt. But what if that is not possible or very difficult? (For example when there is only a old style dos executable and no source code or .obj file are available. Is it then not difficult to rebuild the executable so it will have a 40 bit header? Pelle already said that "rebuilding the DOS exe into a NE exe is not really an option") .
• Possibly it is hard to get link.exe version 5.5x or higher or maybe it goes with Windows Platform SDK and the .NET Framework SDK (as mentioned by Stefan Pendl) which are both very large packages, VERY large given the fact that I am only interested in the small file link.exe ... .
• I like to use POLINK with PellesC because POLINK is the right linker specially made for PellesC. Using link.exe in PellesC does not "feel" right. (this is of course a very subjective argument)

FINAL REMARKS:

In my previous posting on this topic (http://forum.pellesc.de/index.php?topic=2423.0), I proposed a way of using ONLY PellesC to achieve the desired result (to use a different DOS-EXE as a stub in an executable generated from a PellesC project).

Given the difficulties in trying to achieve this result in another way with the aid of link.exe (which could possibly be used to convert the dos-exe into a dos-exe with 40 bit header) and given the difficulties in obtaining a dos c compiler that can generate dos-exe files with 40 bit header, it seems not unreasonable to say that my proposed approach deserves some more attention (and verification) because this could be worthwhile.

[Pelle]

I don't have much to add right now, except:
1) Microsoft says 16-bit LINK version 5.5x, which should probably not be confused with a 32-bit LINK version x.x...
2) The 'KNOWEAS' name is unique enough to search for in Google (for example). I see a number of hits, but I havn't actually read them...

[Bastiaan]

Many thanks Pelle for your help in this topic. I believe there was indeed a confusion as to which link.exe program is to be used and you indeed mentioned 16-bit link in your first posting on this topic. However, as I said before, I have little experience in using linkers directly. I have probably used them a lot as part of an IDE like PellesC without knowing it! So I wasn't aware of the difference between 16-bit linkers and 32-bit linkers. Thank you for clarifying this confusion.

Again, I didn't succeed. So here a brief summary of what I did (in the hope someone might help):

Looking for the right 16-bit version of link.exe on google (also using knoweas as a keyword), it became apparent that LNK563.exe is important.

I found somewhere (not on an official microsoft website though) via google the file LNK563.exe. Running that file (hopefully that is safe to do!) on my computer, extracted a file link.exe which when run in the command prompt states that it is microsoft segmented executable linker version 5.60.339. Hopefully this is really true and there is no malignant virus, trojan horse or what else in this file.

So replacing polink with this version of link and then renaming link.exe so PellesC will be tricked into using link.exe and rebuilding the project WindowsStubMyPr (mentioned in my previous posting on the current topic) with the following linkflags:

-subsystem:windows -machine:x86  -KNOWEAS:16-bit -stub:"C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\HELLO.exe" kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib

resulted in the following error message by PellesC:

Building WindowsStub.obj.
Building WindowsStubMyPr.exe.
*** Error: polink.exe -subsystem:windows -machine:x86  -KNOWEAS:16-bit -stub:"C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\HELLO.exe" kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib -out:"C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\WindowsStubMyPr.exe" "C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\output\WindowsStub.obj"
*** Error: The system cannot find the file specified. 
Done.

I also tried the following linkflags:

-subsystem:windows -machine:x86  -KNOWEAS -stub:"C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\HELLO.exe" kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib

but this resulted in the same PellesC error message.

Finally, I also tried:

-subsystem:windows -machine:x86  -stub:"C:\Documents and Settings\Bastiaan\My Documents\Pelles C Projects\WindowsStubMyPr\HELLO.exe" kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib

but again the same error.

I even tried:

-subsystem:windows -machine:x86   kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib delayimp.lib

(so without stub at all!)

again the same error!

CONCLUSION
It either is not possible to use this version of link.exe to create a dos stub (can be true) or
there is something wrong with the way I have set up the flags (perhaps more likely, in view
of my relatively inexperience with link.exe). Perhaps this is simple to fix, but I have no idea
how this could be done

Could someone please give a hint how to setup the linkflags in this case?

Many thanks in advance

Bastiaan



(PS. I am aware of the fact that the DOS-stub is generally of little interest, so apologies for these lengthy postings. However, I believe, there may be cases where there is a "risk" a program is "accidentally" executed in DOS. For example, people could wrongly assume that the command prompt IS DOS, which is a common mistake. They may then accidentally execute a program that should run in the windows command prompt in DOS or a DOS-emulator. In such cases, it might just be a nice feature if the dos-stub could be a little more sophisticated than the standard message "this program cannot be run in dos mode")

[Vortex]

Bastiaan,

You can get the 16-bit DOS linker Version 5.60.339 from here :

http://website.masm32.com/microsoft/Lnk563.exe

Rename link.exe to link16.exe

The custom stub :

Code: [Select]

.model small
.stack
.data

string  db 'This is a custom DOS stub.'
        db '$'    ; the DOS string terminator

.code

start:

    mov     ax,@data
    mov     ds,ax
    mov     dx,OFFSET string
    mov     ah,9
    int     21h
    mov     ah,04Ch
    int     21h

END start

Assemble the source code of the custom stub with Masm and link the object file :

Code: [Select]

\masm32\bin\ml /c CustomStub.asm
\masm32\bin\link16 /KNOWEAS CustomStub.obj
Attached is a PellesC project built with this DOS stub.

[Bastiaan]

Many thans to Vortex for posting such a nice and clean way of creating a custom stub using assembly language. I repeated all steps and as far as I can see it works perfectly!

I do not fully understand how crt0\crt0.lib works, but I could clearly see its beneficial effect: omitting crt0\crt0.lib from the LINKFLAGS results in a larger executable file than when crt0\crt0.lib is included in the LINKFLAGS. But when crt0\crt0.lib is omitted a valid executable (both in windows and dos-mode) is also obtained. Perhaps sometimes this would be required when the DOS-stub becomes more complex? I don't know, but from a pragmatic point of view I would suggest the following: try to build with crt0\crt0.lib included in the LINKFLAGS and when that does not work, omit it from the linkflags!

I also investigated what happens when the flag \KNOWEAS is omitted and found that this flag is indeed essential: when it is omitted and the PellesC project is build there is the error message: "polink error: missing full MS-DOS header in stub file".

Reverting to my original problem statement: Is there an easy way of using an executable created with turbo-c version 2.01 as a tub in a PellesC project? I posted earlier a proposal for this, but I am still not completely sure this approach is valid and what it's potential limitations are. I have now tested it with a sligtly more complex stub and it seems to work okay. But that does not prove anything of course...

So it would be great if somehow LNK563.exe could be applied, also for this problem. To investigate this, I tried the following:

I compiled a simple "hello world!" program with turbo-c v.2.01. This resulted in the file HELLO.obj.

Next, I tried to use link16.exe (obtained from LNK563.exe) in the following way:

\masm32\bin\link16 /KNOWEAS HELLO.obj

this resulted in the file HELLO.exe. However, when HELLO.exe is run in DOS-mode, it cannot run properly and there is an error. Although this probably demonstrated that link16.exe cannot be used for .obj file generated with turbo-c v.2.01, I still tried to use HELLO.exe as a stub in the PellesC project, but as could have been expected, when the resulting executable is run in DOS-mode it cannot execute properly and there is an error. (in windows "mode" the program runs fine however).

Perhaps a way out of this situation is the following scheme:

(1) disassemble HELLO.exe

and then follow the scheme similar to the one proposed by Vortex:

(2) assemble the disassembled file again using MASM32 (perhaps after adding things linke ".model small" at the top of the asm file). In this way a new HELLO.obj is obtained.
(3) link using \masm32\bin\link16 /KNOWEAS HELLO.obj. In this way a new HELLO.exe is obtained.
(4) use the obtained new HELLO.exe as a stub in the PellesC project (in the same way proposed by Vortex)

However, when I try to disassemble HELLO.exe using MASM32, I get the following error:

'HELLO.exe' does not appear to be an Win32 PE Portable Executable file.

[Vortex]

Hi Bastiaan,

crt0\crt0.lib is a tiny C run-time startup library reducing the size of the final PellesC executable. You are completely free to use it or not. You can even create more sophisticated startup modules to handle various initialization tasks like memory allocation etc. before passing the control to the main module. Using crt0.lib, you get an executable of 2560 bytes.

KNOWEAS must always be used to create custom DOS stubs.

Code: [Select]

\masm32\bin\link16 /KNOWEAS HELLO.obj
The hello.obj module compiled with Turbo C should be linked together the proper C run-time libraries shipped with the Turbo C 2.01 package. The command-line above does not specify any entry point for the executable and C run-time libraries, this is why your application crashes.

I created a custom stub with Turbo C Version 2.01. To avoid the usage of TC's C run-time libraries and to get a smaller executable, I coded my own initializion routine named crtSTART.asm.

DOSstub.c :

Code: [Select]

extern printf(char *string);

int main()
{
printf("This is a 32-bit Windows application.$");
return 0;
}       

The crtSTART C run-time startup module calling the external main module :

Code: [Select]

.model small,c
.stack
.data

main PROTO

.code

start:

    mov     ax,@data
    mov     ds,ax
    call    main
    mov     ah,04Ch
    int     21h

END start

The printf procedure :

Code: [Select]

.model small,c
.stack
.code

printf PROC string

    mov     dx,string
    mov     ah,9
    int     21h
    ret

printf ENDP

END

Building the DOS stub :

Code: [Select]

d:\tc\tcc -c DOSstub.c

d:\masm32\bin\ml /c crtSTART.asm

d:\masm32\bin\ml /c printf.asm

d:\masm32\bin\link16 /KNOWEAS DOSstub.obj crtSTART.obj printf.obj
The size of DOSstub.exe = 590 bytes

In the project options dialog box ( Compiler settings ), I checked the "Omit default library name in object files"  box. It should be preferable to omit PelleS C run-time library if you wish to use other libraries like crt0.lib

[Bastiaan]

Thank you Vortex,
Your explanation+attachments clarify things a lot.
It works perfectly and describes a clean way of doing things.

The hello.obj module compiled with Turbo C should be linked together the proper C run-time libraries shipped with the Turbo C 2.01 package. The command-line above does not specify any entry point for the executable and C run-time libraries, this is why your application crashes.

I aslo tried to follow the above suggestion. I have tried many ways of including more of the .obj and .lib files of the turbo-c package, but I don't know which one(s) to select and it seems the more I use, the more error messages.

Any further help with this would be highly appreciated!

By the way, the above still requires a .obj file, but what to do when there is only a (turbo c v. 2.01) .exe file and no .obj file?

Bastiaan

[Vortex]

Bastiaan,

Here is where you can find information about the libraries coming with Turbo C Version 2.01 :

http://dn.codegear.com/article/20841

HEADER FILES/LIBRARIES
  ----------------------
  C0S      OBJ  -  Small model startup code
  C0T      OBJ  -  Tiny model startup code
  C0L      OBJ  -  Large model startup code
  MATHS    LIB  -  Small model math library
  MATHL    LIB  -  Large model math library
  CS       LIB  -  Small model run-time library
  CL       LIB  -  Large model run-time library
  EMU      LIB  -  8087 emulator library
  GRAPHICS LIB  -  Graphics library
  FP87     LIB  -  8087 library
  TLIB     EXE  -  Borland Turbo Librarian
  ?? H    -  Turbo C header files
  <SYS>         -  Subdirectory with SYS*.H header files
  C0C      OBJ  -  Compact model startup code
  C0M      OBJ  -  Medium model startup code
  MATHC    LIB  -  Compact model math library
  MATHM    LIB  -  Medium model math library
  CC       LIB  -  Compact model run-time library
  CM       LIB  -  Medium model run-time library

Here is a quick trial :

Code: [Select]

#include <stdio.h>

int main()
{
 printf("Hello world!");
 return 0;
}


Code: [Select]

D:\TC>tcc -c Test.c
D:\TC>\masm32\bin\link16 Test.obj lib\c0t.obj,,,lib\cs.lib
Replacing c0t.obj with c0s.obj gives an incorrect result :

Hello world!Null pointer assignment

I guess you should move to a more suitable 16-bit C compiler as TCC 2.01 is very old. If a remember well, some MS driver development kits are providing 16-bit C compilers.

[Bastiaan]

Vorte, thanks again. I was able to repeat everything you wrote.

I tried to do the same but now using the newer Turbo C++ version 3 (probably not still "new" enough...).

There was a curious & interesting result, which I would like to share with everyone here....

First, what I did:

I compiled HELLO.c with TurboC++ (v.3) and obtained HELLO.obj.

Then I went to the windows command prompt and issued the following command:

\masm32\bin\link16 /KNOWEAS HELLO.obj \tcpp3\lib\c0t.obj,,,\tcpp3\lib\cs.lib

the following messages appeared:

Microsoft (R) Segmented Executable Linker  Version 5.60.339 Dec  5 1994
Copyright (C) Microsoft Corp 1984-1993.  All rights reserved.

Definitions File [nul.def]: LINK : warning L4021: no stack segment


Next, if I run HELLO.exe, the following output is obtained:

Hello, world
Hello, world

There is no error message, only it seems that the program is executed twice! That is very stange... The original source code really has only one printf("Hello, world\n"); statement.

Also, if I use HELLO.exe as a DOS-stub for a program compiled with PellesC, there is no error message and
the program seems to be included correctly as a stub. But again, when run in DOS-mode, the output is:

Hello, world
Hello, world


So it seems to go wrong at the stage where link16 is used.

Perhaps the observed effect can trigger someones inspiration to find a solution to the problem of how to use TCpp3 to create customDOS-stubs for programs compiled with PellesC?


Regards,
Bastiaan