Re: Re: [UnixOS2] libc

Holger Veit wrote:
> 
> On Fri, Jun 20, 2003 at 06:20:19AM -0700, Ilya Zakharevich wrote:
> > On Fri, Jun 20, 2003 at 02:13:34PM +0200, Holger Veit wrote:
> > > On Fri, Jun 20, 2003 at 02:15:34AM -0700, Ilya Zakharevich wrote:

[snip]

> > > If we set off_t to longlong, structures like struct stat will change.
> > > We could get around with a specific distinction of struct stat and
> > > struct stat64, forcing each one to explicitly request the 64 bit APIs.
> >
> > Correct, without this backward compatibility breaks.
> >
> > > It is unlikely to happen
> >
> > What is "it"?  People putting -DEMX_LARGE_FILES into GCCOPT?
> 
> If you need to recompile stuff anyway, there is no reason to remain
> compatible to old conventions.

What do you want to say? That compatibility is not important? That you
can change the specifications as long as you can "recompile" the code?
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? Because you can recompile it with gcc
which needs the libc from November 2003? Great idea, especially for
software which need 20 special tools for recompilation you've never
heard from. So you can either change BEGINLIBPATH for every program
or you download the 200 MB build package every month and compile all
the stuff for 2 days non stop?
If it's absolutely necessary to break compatibility we can do it once
and only once. And not again 4 months later when we switch to ELF
and again 3 months later if a new incompatible link handling scheme
is implemented. 99% of all OS/2 user don't have the time and the
motivation to reinstall basically their whole system just for one
new program that requires a new and incompatible libc.

[snip]


> > > Besides:
> > > I don't think anyone needs backward compatibility at all for a DLL which
> > > is then not even named EMX*.DLL even if it stemmed from EMX and maybe
> > > shared 90% of the code.
> >
> > Absolutely.  But my point is that a backward-compatible DLL which
> > *does* share the name will be many many times more useful - and will
> > require only minimal work to set up.
> 
> Feel free to do so. Be aware that you need some considerable modifications
> alone to get EMX to work *correctly* with any gcc > 2.8 (or 2.9). You
> might have a small look at some files in the source tree with the
> innocent extension .cc (exception and new handling). Keep them in there,
> and you need at least for this two compilers (2.8.1 and 3.x), or leave
> them out (won't link without removing ordinals), or change them to
> the libgcc-3.x.a versions (3.x will short-circuit them in EMX*.DLL
> with the own libgcc.a) and break API compatibility.

I don't know why EMX needs C++ internally. If this depends on the
gcc version we can't do much about it and C++ is absolutely not
related to our Posix discussion. We could e.g. consider to put the
compiler version dependent stuff into a static library.


> This can be ironed out, of course, but don't expect anything from me
> on this anymore.
> 
> > > Do you want Unix or EM(i)X?
> >
> > Sorry, I do not know what is meant by any one of these terms here.
> > IMO, one of the most devastating point of views of EM's is the
> > opposition of "OS/2 applications" and "Unix applications" as two
> > targets for use of EMX.  For me these terms do not mean anything.
> 
> Too bad for you. Meanwhile, even Windows has almost managed, thanks
> to large disk partitions, that the only drive letters the ordinary
> user knows nowadays are C:

You mean Windows has to be installed on drive C: or 99% of all Winxx
users don't know that they can use another drive letter for this?
(Can they? I'm not familiar with XP)


> for the disk and D: for the CDROM (A: is
> obsolete, 

You mean the standard Windows user has exactly one hard disk and one
CDROM? No Network drive, DVD drive, MO drive, ZIP drive? What do they
do with their old hard disk if they buy a new one? They throw it into
the basket? Who prevents you from installing OS/2 onto your only
C: partition?


> and USB or other external disk devices are handled by some
> obscure software).

In other words USB an other external devices are accessed by some
proprietary software using an proprietary API? And if the vendor
of the devices and the vendor of your OS isn't interested in these
devices any more you can't use them any more? Great deal. I knew
Winxx uses a superior technology but I didn't know it's _that_
superior.


> Since the CD is now merely a container for newly
> to be installed software (music is again not handled as files), one can,
> without restricting generality, say that Windows no longer has drive
> letters.

You mean the "default Winxx user" doesn't know how and why to create
a separate partition for programs, games and data? You mean 99%
of all Winxx users throw away their old hard disk if they buy a new
one? Because using d: for the 2nd hard disk would be evil?


> It understands them somewhere, and if you explicitly ask for
> them, you can still find them, but it won't need them anymore. Some
> day they will disappear 

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?
Sounds like Microsoft. :-(


> 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? I'm impressed. That's a real
proof of superiority.


> and noone will miss them.

You mean 99% of all Winxx users won't use any applications or games
that are older than 2 years? Might be.


> OS/2 is this way no more advanced than CP/M almost 20 years ago which is
> itself a cheap clone of certain DEC operating systems; cheap in
> the way that the underlying conventions have been copied without
> the more fundamental concepts.

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?


> 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" ...


> all, programmers keep their copies of VAC++ or Watcom, or maybe even
> CSET/2 and MASM for that (or stay entirely out of the C/C++ ara and use
> Java, for instance - ignored here). If there are still efforts, they
> are concentrating on porting work. Guess where the most important repository
> for portable software is. So, what tools does one need?

Oh, sure, taking into account the great VAC++ support by IBM changes
everything. Oh, wait, was there any support by IBM at all? And Watcom,
great deal. Everybody who used to use EMX may rewrite his code for
Watcom if he wants to be up to date to current C standards. Great.


> > We are discussing APIs.  The targets are:
> >
> >   a) Have APIs conform to the documentation as much as possible;
> >
> >   b) Have the documentation conform to standards as much as possible;
> >
> >   c) Have support for as many APIs' entry points as possible.
> >
> > I just do not see where the opposition of Unix/OS2/EMX comes into this
> > picture.
> 
> ANSI != POSIX.

Not to forget 0 != 1. And this proves exactly what?
ANSI is the rudimentary C standard all compilers should comply to.
Posix is a Unix-like system independent API. Why should a compiler
not be able to comply to both standards?


> a) and b) is secondary, 

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.


> nice to have, but c) helps the programmer. All the
> experiments so far aimed at helping the programmer to get some nice
> software from Unix to OS/2. Now you are proposing that it shoudn't be too
> easy for the programmer, because he mustn't use an optimally tailored tool
> for the purpose, but one that is religionusly or politically correct, because
> it is "compatible".

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


If you think some smileys are missing in this posting you're right.
At some point I didn't know whether I should laugh or cry. Maybe you're
right, maybe not. Maybe you've had this discussion many times but
there are still many people who aren't convinced. And I think I'll
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.
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).
And second, there must be long term compatibility for programs.


Bye,
Andreas