Xref: utzoo comp.os.msdos.programmer:3236 comp.windows.ms:9116
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!emory!gatech!ncsuvx!mcnc!rti!bcw
From: bcw@rti.rti.org (Bruce Wright)
Newsgroups: comp.os.msdos.programmer,comp.windows.ms
Subject: Re: Programming Windows 3 applications
Summary: Not quite as easy as that ...
Keywords: info wanted
Message-ID: <1991Feb8.150917.19450@rti.rti.org>
Date: 8 Feb 91 15:09:17 GMT
References: <26610@uflorida.cis.ufl.EDU> <11258@jpl-devvax.JPL.NASA.GOV> <985@tuura.UUCP>
Followup-To: comp.os.msdos.programmer
Organization: Research Triangle Institute, RTP, NC
Lines: 51

In article <985@tuura.UUCP>, risto@tuura.UUCP (Risto Lankinen) writes:
> altman@sbstaff2.cs.sunysb.edu (Jeff Altman) writes:
> 
> >{Whether there will be Turbo C++ for Windows speculation deleted}
> >It is still unclear as to whether Borland will provide an entire
> >library set to enable Windows programming without the SDK.
> 
> Well, the libraries aren't actually needed for much more than resolving the
> import references from Windows' Kernel/GDI/User/other modules, by Microsoft
> development products (at their current state), either.
> 
> This is to say, that programming for Windows is already possible (at least in
> principle) with only the 'lowest-level' object modules (located in xNOCRT.LIB
> as nocrt.obj and wnull.obj) *and* by knowing the 'argumentation' for function
> calls (#defines and prototyping).  By running the IMPLIB for each kernel.exe,
> gdi.exe and user.exe one then gets the libraries...

You can use something like Turbo C now to program in Windows, but it's
a _bit_ more complex than this article seems to imply.

The problem is that the Windows calling sequences are different than
the normal C calling sequences.  First of all, most Windows functions
use the Pascal calling sequence;  I don't know if Turbo C supports that
format or not (I'm not familiar with Turbo C).  The Pascal calling
sequence has the _subroutine_ responsible for removing the arguments
from the stack;  it does this by using the "ret n" instruction rather
than just the "ret" instruction.  That's the major difference, anyway;
there's a more minor difference that the arguments are on the stack in
the reverse order than the C calling sequence.  But if you can prevent
your compiler from removing the arguments from the stack in the calling
routine a la C, the argument order can be kluged around by just passing
the arguments in backwards.  If you can't get your compiler to use the
Pascal calling convention, it's always possible to write assembler
language jacket routines for each of the several hundred Windows
functions.  (Have fun :-).

Another critical issue is that a Windows routine has some special stack
fix-ups that are used to allow segment movement during garbage collection.
If you are proficient at Windows and assembly code anyway, you can make 
the appropriate fixups in assembly language "jacket" routines, but the
result is not very intuitive, especially if you're just learning Windows.
The result of failure to provide the appropriate stack fix-up isn't very
subtle - it's usually Big Red Switch time.  I do know that Turbo C does
not provide the proper stack fix-ups.

I don't think I'd recommend this setup to anyone learning Windows unless
they were a masochist.  I'd suggest waiting to see what Borland is 
supposed to be announcing next week & see if it is closer to a real 
Windows development language than what it is now.

							Bruce C. Wright