Re: When CString doesn't work

In article news:<6j79a1lqoj77d9au46ouno66n65j5u47p1@xxxxxxx>, Joseph
M. Newcomer wrote:
> [I wrote]
> >I'm referring, in part, to the fact that MFC's tchar.h is a
> ****
> It is not "MFC's", it is a header file independent of MFC

Sorry, yes, Sloppy of me. I should have written "Microsoft's tchar.h".

> >Microsoft-supplied header (and bears a Microsoft copyright). You
> >might have to ship that header as part of your app if you ported
> >it to other applications (and I've no idea what the licensing
> >implications of that are).
> ****
> It should be obvious that you could write your own. With all due
> respect to copyright law, it is difficult to copyright something
> that is as obvious as the way tchar.h works.

Of course, yes, and I have done so when occasion demanded. I was just
pointing out that tchar.h is not provided for you for free on all
platforms.

> > ... (my linux boxes don't have it, for example) ...
[snip]
> Well, those who use free software are doomed to the problems that
> naturally follow on. As I said, I don't use free software because
> I can't afford it.

I've never seen tchar.h supplied on commercial closed-source unix
boxes, either.

Don't be too quick to knock free software. It can be an expensive
mistake, but by no means always. I avoid closed-source free software,
but when the source is available (so one can assess the code quality
for oneself) it can be a wise investment (of time and effort; but not,
of course, of money). That's very often not the case, of course, but
it can be.

> If you use CStrings, you already have lost portability ...

My point: Don't be tricked into using CStrings just because they
change their nature when you define UNICODE.

> Presumably, there is a std::tstring,
> or you could use a header file to define one.

There isn't. You can. I do.

> I would never code something that could not be put into Unicode
> unless there was a specific Statement Of Work that insisted on
> 8-bit-only. In which case I would advise the client that they
> were almost certainly making a mistake

I'm liable to do the same ... though Unicode compatibility is usually
something that my clients insist upon anyway (that may be more common
here in Europe than in the US).

> (counterexample: I've woked with DoD sites, who clearly say "We
> don't want someone whose language isn't English using this
> software...")

I can believe that ... of course, there are a lot of non-English
languages that can be written without Unicode (and a lot of loyal US
citizens whose first language isn't English).

> tchar.h is not ware of std::

True. tchar.h isn't aware of any C++ (as opposed to C) construct.

My point was that the narrow/wide function mappings provided by
tchar.h (even in VC) only map C functions, not C++ functions/classes.
To use portable C++ in a unicode-compatible manner one needs more than
tchar.h even on the platforms that do supply it. It's a good starting
point, though.

> I've consulted with clients who have had device drivers written in
> gcc. They are unable to rebuild the drivers using standard Microsoft
> tools, but that is OK, because uniformly the drivers are trash,

I can't imagine why anyone would choose to use a non-Microsoft
compiler to write drivers for Windows -- unless, maybe, they were
trying to start by porting an existing driver from a system on which
gcc was the standard system compiler? It still sounds crazy, as the
driver models are quite different on different platforms. I'm not
surprised the results were buggy.

> I suffered enough under Unix that I never want to see it or any of
> its derivatives again. I detested the system when I had to live
> with it (poor documentaiton, amazingly poor code most of the time,
> "the source is the documentation", ...

It's a bit unfair to single out unix for that criticism: I've seen
enough patchy, incomprehensible, and just plain incorrect
documentation from Microsoft in my time, too. Documentation for
writing device drivers -- unless you wanted to make only very small
changes to standard drivers supplied by Microsoft themselves ("the
code is the documentation") -- is the worst of all.

It's been a while since I did any serious driver work on Windows (a
Win95/98 VxD that took over hard disk encryption from an In13
redirector was the last big one) but I don't suppose the situation has
changed much.

> The worst problem of VS7 is that people who have never seen VS in
> any incarnation recognize that it is by far the worst excuse for
> a development environment ever produced by anyone in history.

There's a lot of truth in that ... which is a shame because VC7.1 is
actually a pretty good native code C++ compiler.

Cheers,
Daniel.


.

Relevant Pages

  • Re: Command To Allow Safe Removal of Hard Drive?
    ... Thanks for the distinction between volume and disk, ... No, it just prepares the drivers from Symantec for device removal, this ... upperlayered drivers in the storage IO stack, ... Nice claim, any documentation about this... ...
    (microsoft.public.windows.server.general)
  • Re: FC4 and FC6 + ethernet printer - Update
    ... There are drivers for LPD.lpr, CUPS, CUPS-wrapper (apparently ... The documentation on the web pages is excellent. ... printed via CUPS and scanned in GIMP. ... still couldn't get it to work, so I tried their email support. ...
    (Fedora)
  • [git pull] Input updates for 2.6.30-rc2
    ... to receive updates for the input subsystem. ... drivers, new documentation, update for bcm5974 to support touchpads on ... bcm5974 - add documentation for the driver ...
    (Linux-Kernel)
  • Re: 802.11 status and futures
    ... >>new framework for doing scanning. ... These changes affect all drivers so ... > looking at the source and searching for documentation I still lacked ... > software, which one needs what kind of hardware support, what needs to ...
    (freebsd-arch)
  • Re: Runs with Linux (tm)
    ... On Mon, 12 Dec 2005, David Lang wrote: ... > the sticker) and if Linus could define a suitable level of documentation ... > of the hardware I think that that should very quickly lead to an in-kernel ... > I would not like to see it for external drivers, ...
    (Linux-Kernel)