Re: Re: [UnixOS2] libc

On Sun, 22 Jun 2003, Andreas Buening wrote:

> It's okay if the Mozilla build in March 2004 requires the libc version
> from January 2004 while the file utilities require the incompatible
> version from September 2003?

Even though, I wouldn't like such a situation, where is the essential
problem _if_ all those libc version are in differently named DLL's?
OK, allocating/freeing memory is going to be the same kind of nightmare
that it currently is on Windows, if you mix libraries/DLL's using
different libc versions and don't carefully choose which libc you want to
use, but that's basically a problem known on OS/2 as well (just try to
have some function from a VAC++ compiled library allocate some memory and
free it in an EMX compiled executable. Hm, actually, that might be less
of a problem then I believe ...)

> I don't know why EMX needs C++ internally.

It doesn't. But if you want to be able to use C++, that needs some support
deep in the internals of EMX. And since C++ was a rapidly evolving
standard, compilers have been evolving rapidly as well, so there are quite
some incompatibilities.

> You mean the standard Windows user has exactly one hard disk and one
> CDROM?

Yes, definitely, maybe some additional network drives, maybe a DVD instead
of CDROM.

> do with their old hard disk if they buy a new one? They throw it into
> the basket?

Together with the whole computer, yes. Don't forget that you do need
completely new hardware every 3-4 years in Windows-country. So why bother
with individual new harddisks?

> In other words USB an other external devices are accessed by some
> proprietary software using an proprietary API?

Typically there's a hard drive emulation layer, AFAIK. But if the vendor
doesn't care to support it anymore (or if Windows changes its driver
modell once again), you essentially _are_ lost, yes.

> You mean the "default Winxx user" doesn't know how and why to create
> a separate partition for programs, games and data?

The default Winxx user meanwhile gets its box with WinXX pre-installed
to the only partition existing on the hard drive and without installation
media, yes. Unless you buy stuff like PartitionMagic (newest version), you
are unable to repartition.

> You mean 99%
> of all Winxx users throw away their old hard disk if they buy a new
> one?

99% don't know what a hard disk is. They have "computer", monitor,
keyboard and mouse. If you're lucky, they now about CDROMs and CDs. ;-)

> Because using d: for the 2nd hard disk would be evil?

Because, if you buy a new computer anyway, why not buy one with a larger
hard disk. :-( 

> You mean one of the next Winxx releases will do an incompatible change
> and remove the drive letters? And all old applications that expect
> a drive letter will fail so that users will have to buy new ones?

Why not? Sounds like switching from Win3.1 to Win95.

> > like a usable DOS box, 
> 
> Usable DOS box. That's an oxymoron, isn't it? ;-)
> You mean one of the next Winxx releases will have no shell where
> you could enter commands directly?

Probably just that it won't be compatible any more. Just try running any
DOS games in NT/2000/XP's DOS box and you will notice the difference
between "usable DOS box" (like on OS/2) and "Windows' DOS box".

> You're right. Winxx is much superior. When did they stop to sell
> the last DOS clone WinME containing the same 20 year old bugs?

Don't know, but AFAIK it's quite difficult to buy anything but WinXP
nowadays.
  
> > No one will seriously use EMX for writing "OS/2" software anymore; if at
> 
> If I got 1 cent for every time somebody said "Nobody ever needs xyz" ...

Actually, EMX was always used almost exclusively for porting software,
wasn't it? If you've been developping OS/2 only software, VAC++ or
similar was the "natural" choice. And for such projects, there really is
no reason to switch to gcc, is there? "Porting" Mozilla, OpenOffice or
whatever is a different thing.

> Oh, sure, taking into account the great VAC++ support by IBM changes
> everything. Oh, wait, was there any support by IBM at all?

Irrelevant for existing OS/2 only software. The successfully worked around
VAC++ bugs by now ...

> > (POSIX and ANSI)
> Why should a compiler not be able to comply to both standards?

There are contradictions between both standards. Only on minor details, 
but they do exist. :-(

> Ehm, hello? If the API doesn't conform to the documentation then the
> API is mostly useless, and if the docs do not conform to any standard
> then it's nearly impossible to write portable programs.

Well, if the API behaves the same way as on Linux or BSD, it doesn't
really matter, that it doesn't conform to an official standard, does it?
And if the documentation for some function is not quite up to date, it's
not that important either, as long as you know that e.g. Linux man pages
give the correct description.

> Hello? The presence of an _chdir2 entry point prevents the programmer
> in porting Unix applications?

No, but strict ANSI compliance would prevent porting Unix applications as
"Unix API" is _not_ strictly standard compliant. 

> speak for the majority of the people on these mailing lists if I say
> that emx (or whatever its future name will be) must be able to compile
> classical OS/2 programs _as_ _well_ _as_ ports of Unix software.

Breaking that behaviour wasn't at all the point (at least not _my_ point).
I rather think of stuff like fread/fopen/fwrite/fseek silently supporting
large files. This _is_ incompatible with existing applications, but unless
they do something stupid/buggy (like assigning off_t's to int variables),
recompiling is enough to make them use the new API - and if they don't
need large files, even ignoring said stupid bugs and just recompiling
makes the application work again.
Meanwhile I do believe that this doesn't necessarily mean breaking binary
compatibility. Whoever thinks that it is important enough should be able
to take existing implementations, rename them to
fread32/fopen32/fwrite32/fseek32 and assign the "right" ordinals to those
and everything should work fine, if I understand the concept correctly.

I.e. just get the thing started, get as much Unix compatibility while
marking possible incompatibilities with EMX and resolve those later by
suitable wrappers or duplication of existing code. Once we do have e.g.
"setuid" we can still discuss on whether or not the existing ordinal
should be used for the dummy implementation or the real one.

> We can't know how the Watcom project will go and lots of people
> want to write portable programs which is easier with emx than with Watcom
> (from what other people said, I myself don't use Watcom).

Well, if you're using gcc on the other platforms, emx certainly simplifies
things. OTOH, if portable means Linux/Windows/OS2, you can just as well
use Watcom, _if_ you start from scratch.

	Regards,
		Stefan