You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by jlwpc1 <jl...@earthlink.net> on 2000/05/11 15:05:34 UTC

Windows - tchar.h

From: William A. Rowe, Jr. <wr...@lnd.com>

I changed the subject so the Unix people could move on (or stay and learn). :)

Also sorry I haven't answered back  - I've been busy. Days and days of rain but finally some sun - time for yard work. 

First Windows programming is very complicated. There are so many "features" that no one person can possible know/understand it all. 

> > Yes Win32 does offer functions to do this but NT/W2K/Win64 OS 
> > also does this every time it "runs" any Apache Server 
> > "call/function/action".  NT/W2K/Win64 are Unicode "full time" systems.
> 
> I disagree entirely with your phrase 'Apache Server call...' - it only
> translates Win32 API system calls (you are correct, the API is native
> unicode and must translate constantly).  These are minimal under Apache,
> the example I can think of include the registry (used when loading and
> installing the service). 

So you have an Unicode version and an Ansi version of Apache Server up and running to make this comparison?  It's not that I am saying Unicode will be faster - just feature ready for NT and up computers and may be faster - you let me know.

Anyhow, it has been years and I no longer "do Windows" daily but please tell me when Windows and Win32 changed.  Win32 is a programming spec and does not tell the OS how to "accomplish its work".  That was because Win32 was suppose to be OS free.

Win9x OS runs DOS for Win32 with very little Unicode (most is buggy except maybe the little for MessageBox to report no Unicode support), but lots of DOS. Say if someone did it right PlayStation OS could run Win32 with no Unicode (or maybe PlayStation handles Unicode????). But NT/W2K/Win64 OS is Unicode - not because of any Win32 saying it has to be but because MS wanted a Unicode "featured" OS. The world is not a char pointer!

A lot of people do not yet get the idea of the different usage of the three words Windows, Win32 and OS. Windows is say a catch-all term for programs running on DOS /Win9x/ NT/ W2K/ or Win64. Win32 is a programming spec (and not C run time or Basic or whatever language that will use some Win32 "actions"). OS (how a computer operates).  The OS of Win9x and the OS of NT and the OS of say some mainframe can all run Win32 but are all different in operating style (hardware/drivers/etc). 

Win32 has no strcmp() function - it is called lstrcmp().
Win32 has no beginThread() function - it is called CreateThread().
Win32 has no malloc() function - it is HeapXXX().

The golden rule was suppose to be - program to Win32 specs and the same source should run on any OS that did Win32 "actions". (Sure - I did say was suppose to be!) 

If you do not compile NT code under the define Unicode ( and Win32 does not make you -but MS wishes it could have - no need to carry old programs, etc), then without defining Unicode, the NT OS "translates" everything to Unicode, whoa one should never say never and never say everything:),  so the Unicode OS can work!   Please look at ntdll.dll.  

> Since the winsock api is -NOT- unicode, it is
> really irrelivant.

Say what?  Winsock is a buffer based (just double your buffer) and/or Unicode aware library, and silly old me, I must get my glasses checked because I wonder just what is all that Unicode stuff in the Winsock include files?

You know I could go on and on but lets keep to one subject per message.

This one message is - Why isn't the Windows version of Apache Server using the tchar.h include file instead of say string.h, stdlib.h and etc.? 

If one started to program a Windows program (C run time or even a Win32 program) it might flow as follows:

#do some defines needed for picking OS, Winsock version , COM and etc.
#include <windows.h>
#include <tchar.h>
#include "user includes"

Rest of code good old Win32 spec code.

Now there is one source file that could be used on Win9x, NT/W2K and Win64 all based on defines.

If the programmer defined Unicode - all Win32 functions will default to Unicode.
If the programmer defined _Unicode - then the Unicode version of the C run time functions will be used. There are also SBCS defines and MBCS defines. All sorts of defines. Tchar.h handles a lot for Windows. Some say a very nice feature.

TCHAR someString;

Is someString - Unicode?  MBCS? SBCS?  Well what was defined? 
Unicode was defined, well then it is a Unicode string!

Just look at tchar.h - all sort of C run time string functions, type defines, printf type defines are all ready to go just by having the programmer making a define - for example -- Unicode - all strings functions and chars are unicode ready.  String.h is not.

Put all Apache Server text in a resource file and you have a French, English or FarOutStarWorld Apache system language defaulted server ready to go. String.h doesn't handle this.

So when programming Windows, in order to use all the great features that makes Windows say Windows, one must start with a good basic beginning.  Tchar.h is that first building block that other Windows features may rely upon. So why doesn't Windows Apache Server use tchar.h? 

When porting software - port programming ideas not straight source code. Use all the wonderful Unix http knowledge with Windows features. 

Also perhaps one should quote from the books of the great Windows authors, instead of saying my research only. Pick an author, a book, a page and a paragraph. I most likely still have it close by. 

Hope this helps,
JLW






Re: Windows - tchar.h

Posted by Greg Stein <gs...@lyra.org>.
On Thu, 11 May 2000, jlwpc1 wrote:
>...
>... long post about Unicode on Windows ...
> Hope this helps,

Not at all.

1) it felt a bit condescending, much like "you know Windows, so you're
   telling us peons how it really works" (maybe it's cuz I just woke up)

2) what's your point? you go on and on about Windows and Unicode. so?


If you think Apache should be using tchar.h, then please provide a patch.
Most work gets done when a patch is provided.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/