From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 22 Jun 2003 14:07:14 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 135 ************************************************** Saturday 21 June 2003 Number 135 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : Thomas E. Dickey" 2 Re: [EMX] Re: libc : Marty" 3 Re: [EMX] Re: libc : Andreas Buening 4 Re: [EMX] Re: libc : Holger Veit 5 Re: libc : Sebastian Wittmeier (ShadoW)" 6 Re: [EMX] Re: libc : Stefan Neis 7 Re: [EMX] Re: libc : Sebastian Wittmeier (ShadoW)" 8 Re: [EMX] Re: libc : Sebastian Wittmeier (ShadoW)" 9 Re: [EMX] Re: libc : Stefan Neis 10 Re: [EMX] Re: libc : Stefan Neis 11 Re: [EMX] Re: libc : Holger Veit **= Email 1 ==========================** Date: Sun, 22 Jun 2003 08:55:55 -0400 (EDT) From: "Thomas E. Dickey" Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003, Andreas Buening wrote: > > 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) You can use another drive letter (XP included), but the boot.ini file resides on C: -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net **= Email 2 ==========================** Date: Sun, 22 Jun 2003 11:55:58 -0400 (EDT) From: "Marty" Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003 14:58:32 +0200, Holger Veit wrote: > Having more than one API for a similar purpose basically results in two > sets of tools; those that deal with small (<2G) files, and others that can > handle big ones. You surely want to add such garbage to autoconf/automake > rulesets, don't you? Isn't this how it's done on every other platform? I know on AIX with VAC, we have to define LARGE_FILE_API when we build (which in turn actives a bunch of other #defines to shift the API over from the 32-bit file API). > Watcom C/C++ is now OpenWatcom, so all complaints that this might have been > a good tool, but yet, it was too expensive are now void. But still it is > not dominant, as it is not "compatible". I had used Watcom 10.0 and 11.0 extensively (bought them both, and was very disappointed when 11.0 didn't fix any of the problems I had with 10.0). I tried it for some large projects (MAME) and it fell flat. It was impossible to get WMAKE to get the dependencies right. WLINK crashed because the list of object files was too large. After breaking it up into libraries, I had problems with the optimizer itself crashing with some code, on even the most conservative settings. When it did work, sometimes the optimizer would change my code to the point where it would crash (again, even with the most conservative setting). The debugger locked my system almost every time I tried to use it (even for text mode apps). In short, I wanted to get as far away from it as possible. With the EMX toolset, I could control the dependencies with a makefile. It handled the large number of objects without having to break them up into libraries. The optimizer worked without issue. GDB was usable. I had the capability of doing post mortems with core dumps. In short, it was and is a good tool for native OS/2 development. I'm starting to look again at Watcom now that people are maintaining it who care about it, but I'm still a bit gun-shy. **= Email 3 ==========================** Date: Sun, 22 Jun 2003 13:06:00 +0200 From: Andreas Buening Subject: Re: [EMX] Re: 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 **= Email 4 ==========================** Date: Sun, 22 Jun 2003 14:58:32 +0200 From: Holger Veit Subject: Re: [EMX] Re: libc Admin notice: please don't put emx at citytraffic.de AND emx at xfreeos2.dyndns.org into your To: or Cc:, they are the same host, and result in duplicate postings. One of them is sufficient (os2-unix is of course another list). On Sun, Jun 22, 2003 at 02:20:51AM -0700, Ilya Zakharevich wrote: > On Sat, Jun 21, 2003 at 10:39:58PM +0200, Holger Veit wrote: [...] > > > 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. > > Since one does not need to recompile in most of the situations (i.e., > when one does not need off64_t), there is every reason. So you just open files and read them sequentially? You are sure that stream I/O doesn't rely on seek/tell anywhere? > > > To take advantage of large files, one needs to use DosOpenL(). Using > > > L-version of seek()/tell() is secondary; moreover, no EMX_LARGE_FILES > > > is needed to support applications which do not need to seek far. > > > Effectively, DosOpenL *is* DosOpen *is* DosOpen2 *is* Dos16Open. Follow the > > traces in the kernel. > > I do not care about "effectively". If one does not use DosOpenL(), > one can't read/write files above 2G. I do not see why any other > argument is relevant. You can but this is another story. You don't want to see that the whole "programmers should use different APIs (fseek vs fseek64 or even open/open64) when they want to read large files" argument is as stupid as Bill Gates' comment that "640k is enough for everybody". This is a similar attitude as this technical debate on optimizating the loader by use of ordinals vs. named entries. The whole OS/2 kernel is full of suboptimal code - if one looked at the thunking interpreter in DOSCALL1, one would avoid "32bit" Dos* calls like a plague - topic shift. Having more than one API for a similar purpose basically results in two sets of tools; those that deal with small (<2G) files, and others that can handle big ones. You surely want to add such garbage to autoconf/automake rulesets, don't you? [...] > > This is formally correct, but unacceptable for working ports. > > This depends. Nobody complained about Perl (but Perl is a special > point, since one can edit a Perl script to avoid these calls). > > > The pair getuid/setuid may return or expect uid=0 all the time, but > > not all software delivers this uid. Also code the changes the uid > > (seteuid/reuid, etc.) might later expect that the returned is no > > longer 0. The whole system works for nice weather conditions > > only. Result for porting: short-circuit these functions and adjust > > stuff as needed. > > Then I see no reason why changing EINVAL return to anything else may > break anything. Look at common daemon code that expects *not* to run as root. It issues a seteuid to become another user (like 'mail' or 'oracle' or whatever) and the call a) fails with -1: correct error check will terminate the program. b) succeeds, but is a NOOP. Later the deamon code will be very surprised to find out it is still 'root': correct error check will terminate the program. If a person porting such a thing want to get it work, he will ignore the known EMX behaviour and invent an own mechanism that returns the "correct" behaviour for this process. Maybe by rewriting the logic of the setuid family at least to the degree needed, or by commenting out error checks. I don't know how many people have invented workarounds for prominent problems like strcasecmp, or setuid/setpgrp/setsid, or setitimer. strcasecmp is among that the most harmless candidate. > > > There are some broken ports lying around. Recompiling such a port > > > with new, more correct, headers/libraries will require some work. > > > > > > If yes, I do not consider this as a valid argument against correcting > > > headers/libraries. > > > > If you change headers, you modify semantics. I don't consider this as > > preserving compatibility anymore. > > There is a compatibility and compatibility. Making a former error > condition into something which is documented it might have happened is > of the latter ;-) kind. I and common users don't distinguish between compatibility and compatibility. The effect is just: this damn thing used to work befor, and now it doesn't anymore. It doesn't help whether it is then documented. > But other people have other agenda. They need different approaches. Maybe. Maybe not. But you should not forget that this here is not a customer/vendor relation. The customers don't pay any efforts or spent lifetime to the people who (could) contribute. This in turn means, according to another proverb: If you pay the orchestra, you decide what they'll play. Not these other people with their other agendas. As the EMX code is public, anyone of these can, in full agreement with the GPL, modify anything from the name to the content. Without any maintainer. > Of course, if the "victim" would benefit from my "ideas and changes" > only, then this would be a kind of a skewed relationship ;-) - I would > provide all the changes, and all that the "victim" would do is > bothering me to make things better. If you find such a person, well go ahead. > But there is another fundamental difference between you and me: it > looks like you believe that you (and me? ;-) are the *only* persons > capable of a contribution to EMX. My wish for coordinator clearly I don't think so. I rather think that most people are afraid that their contribution will affect the holy grail of compatibility that you and some more people keep holding high. This is closely related to the question of acceptance by "the community", or precisely, by a number of speakers with their own agendas. libemu, or Posix/2, is an example of code that was not accepted by the community, in that it was regularly used in ports and continously improved to weed out the bugs. Why? My opinion is: it was not fully integrated, and maybe at the moment it would be used, a better and greater EMX would come up which would obsolete all this. Now, I doubt that there will be a new EMX "threatening" (by EM, although I can't read his mind), but the panic of suddenly becoming incompatible with whatever mainstream one might imagine is a good explanation of why there is no forthcoming. It was observable while people waited for the great Windows 95 (which supposedly did no longer rely on DOS), then on Win98 (which supposedly was more stable because it was not based on DOS), then on WinME (no DOS, for sure). At the same time, there was a rather stable OS for long already; you know it, but it was not "compatible". Eventually, there was Win2K (still not "correct") and WinXP - but meanwhile there is a whole new generation of software and people forgot about their old software which no longer works. Watcom C/C++ is now OpenWatcom, so all complaints that this might have been a good tool, but yet, it was too expensive are now void. But still it is not dominant, as it is not "compatible". Not that anyone now gets the impression that have, within this mail turned from"con-compatibility" to "pro-compatibility" - I am just giving an explantion that people are trapped by the compatibility curse. M$ did the right thing, from a technical point of view. They eroded the compatibility issue by more and more adding new attractive features which forced programmers to move on and forced users to upgrade. The compatibility trap is deadly for OS/2 or eCS future, as it will severely restrict the options. Now: "deadly" - there is the bad mouth again: OS/2 is dead. Should say rather: stale mate. > indicates the opposite: IMO, there are *many* people who can improve > EMX with a reasonable amount of effort. Technically yes, no doubt. But why didn't it happen then? Don't repeat the strawman "no maintainer" argument: it doesn't work: while many people might not be a genius like EM to invent such a thing from scratch, they can recompile it at least, with own (maybe just small) improvements. Add strcasecmp aliases, and call this EMX 0.9d.1, or call it EMU 1.0.0, and there is public code one epsilon better. Put it up at hobbes, and you are done? You are not done, because the grail keepers will howl - how can you, and ordinal 1234 is not okay for strcasecmp, you should better use 2000, and some code might now no longer compile because there is a #define strcasecmp stricmp in it, and anyway, this has discussed for long and has been reported to EM, and will be done differently in the next EMX patch, etc. etc. blurb. A technically skilled programmer will dare this experiment once, and is then cured for ever from walking into an established minefield. > I even believe that there are many people who "sit" on > (almost-)ready-to-distribute solutions to EMX problems (like I do). But you need a strawman to distribute this, or literally, burn instead of you? > > > 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. > > ??? So what? You have a good chance to shoot yourself in the foot when you attempt to serve two masters. > > a) and b) is secondary, nice to have > > For me a) and b) are tantamount. > > > but c) helps the programmer. > > Without a and b "c" is useless - what good is a feature if you do not > know what it will do. Without "c" one needs to reinvent the wheel > again - pitiful work, but doable. c) is an as clean as possible Unix or POSIX API, so it is documented (this is a) ). The emphasis is on "clean" not "many". I don't care about some DOSish APIs like "_getdrive()", as long as they don't disturb anything, they may remain there - but if they somehow do (say a "readlink() which would return backslash paths) I'd drop them. > "c" is nice to have, no more. And if one can add "c" via an external > library, with no support from EMX, there is no need to mix this into > the current discussion. This effort turned out to be doomed - there is supposedly only one "libc", not multiple ones. More helper libraries will mess up the build system at some place. > Of course, it does make sense to discuss which hooks one needs to add > to EMX to simplify addition of externally supported enhancements... There used to be a distinction between Unix man(2) and man(3), something EMX to some degree also separates. Provided this would be the borderline, one would no longer need EMX at all; you could port libc-BSD or glibc on top of that, and maybe add some OS/2 APIs like EA support afterwards. A design that scatters hooks into internal structures and APIs all over the code reminds me too much on the kernel and PMMERGE - IBM's compatibility curses. Holger **= Email 5 ==========================** Date: Sun, 22 Jun 2003 16:14:40 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: libc Hi, IMHO that discussion seems a bit chaotic. I wonder, which advantages both proposals have (Holger's vs. Illya's). Holger's - new DLLs ---------------------------- advantage: maximum Unix compatibility for newly compiled programs advantage: every old application will continue to work (with old DLLs) disadvantage: old applications won't support new concepts/features Illya's - improve existing DLLs ------------------------------------------ advantage: more Unix compatibility for newly compiled programs (GCCOPT) advantage: even old applications profit from certain changes disadvantage: not fully compatible, some programs may not work any longer Why is the interoperability between old and new applications needed (mentioned by EM)? Where do existing libraries fit into that picture? Can't these concepts be combined? - create new DLLs (like Holger's approach) - test old programs, if they work with new semantics - rename EMX DLL names in executables (but no recompiling needed) Sebastian **= Email 6 ==========================** Date: Sun, 22 Jun 2003 18:05:18 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: 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 **= Email 7 ==========================** Date: Sun, 22 Jun 2003 18:32:50 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003 13:06:00 +0200, Andreas Buening wrote: >Holger Veit wrote: >>No one will seriously use EMX for writing "OS/2" software anymore; if at >>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? There is not much choice anymore with compilers on OS/2. So writing OS/2 programs with gcc is more important than ever. >Hello? The presence of an _chdir2 entry point prevents the programmer >in porting Unix applications? I like drive letters. You can quickly switch between them, and each has its own current directory. The concept of current directory is important - all commonly used operating systems have it; with drive letters you get more then one. They don't have to reflect real hard drives; there is TVFS, Netdrive, LVM, ... Sebastian **= Email 8 ==========================** Date: Sun, 22 Jun 2003 18:45:41 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003 18:05:18 +0200 (CEST), Stefan Neis wrote: >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. Ok. But then compatibility only exists in one direction: You can use old programs with the new DLLs. Not the other way round. Why would you do it? You only have to maintain one set of EMX DLLs and can access all internal structures. But on the other side you are more limited in the implementation. So please someone explain: What good is in accessing the internal EMX???.DLL structures of other applications? Why are you not easily able to use EMU???.DLL? Sebastian **= Email 9 ==========================** Date: Sun, 22 Jun 2003 19:22:05 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003, Marty wrote: > Isn't this how it's done on every other platform? Currently, yes. But still with a target of only having large files in the future. The problem is that one can't mix code compiled _with_ such a define and code compiled without it (e.g. trying to link a large file enabled library from an application that's not supporting large files or vice versa leads to desaster). I really would like to avoid all those problems... > I know on AIX with VAC, we have > to define LARGE_FILE_API when we build (which in turn actives a bunch of other > #defines to shift the API over from the 32-bit file API). I know that whereever I build e.g. wxWindows/GTK, I first have to find out what settings GTK did use in this respect and then reuse the same ones for wxWindows and all applications wanting to use it. It's just great fun. :-( Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 10 ==========================** Date: Sun, 22 Jun 2003 19:24:37 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Sun, 22 Jun 2003, Sebastian Wittmeier (ShadoW) wrote: > On Sun, 22 Jun 2003 18:05:18 +0200 (CEST), Stefan Neis wrote: > >fread32/fopen32/fwrite32/fseek32 and assign the "right" ordinals to those > >and everything should work fine, if I understand the concept correctly. > > Ok. But then compatibility only exists in one direction: You can use > old programs with the new DLLs. Not the other way round. Sure. However, assuming you want large file support in your new programs, the old DLLs won't help anyway. Also, that has always been the case for EMX. Just try using EMX-0.9c DLL's (or even older ones) with a current program. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 11 ==========================** Date: Sun, 22 Jun 2003 19:48:24 +0200 From: Holger Veit Subject: Re: [EMX] Re: libc On Sun, Jun 22, 2003 at 11:55:58AM -0400, Marty wrote: > On Sun, 22 Jun 2003 14:58:32 +0200, Holger Veit wrote: > > > Having more than one API for a similar purpose basically results in two > > sets of tools; those that deal with small (<2G) files, and others that can > > handle big ones. You surely want to add such garbage to autoconf/automake > > rulesets, don't you? > > Isn't this how it's done on every other platform? I know on AIX with VAC, we have > to define LARGE_FILE_API when we build (which in turn actives a bunch of other > #defines to shift the API over from the 32-bit file API). Do we need to duplicate the same mistake here? > > Watcom C/C++ is now OpenWatcom, so all complaints that this might have been > > a good tool, but yet, it was too expensive are now void. But still it is > > not dominant, as it is not "compatible". > > I had used Watcom 10.0 and 11.0 extensively (bought them both, and was very > disappointed when 11.0 didn't fix any of the problems I had with 10.0). I tried it > for some large projects (MAME) and it fell flat. It was impossible to get WMAKE to [...] Surely Watcom has its bugs, maybe to a degree it makes it unusable for certain purposes. But then this is an issue whether there are bug reports and how eager the maintainers are to fix them. I was pointing at the entirely different build environment which will require significant modifications before it could be applied as a porting tool. It has been proven as useful in the DD programming area, but the professionals there don't care about conventions and use a tool that does their job. Compatibility is an issue so far only as it applies to kernel APIs and conventions. Holger