> OK. This is starting to not go anywhere. Indeed, which is massively unfortunate. > _EXPORT is a compiler specific thing. Not really. The *necessity* of _EXPORT is format dependant, but it * works* everywhere. > It is 7 characters. > It is not standard C++. > It is not earthshakingly difficult to type. > It is (a little bit) more work. > ELF doesn't require _EXPORT. > It is useful if you want to port to a non-ELF system. > It can be used to document what is meant to be external and what is > not. > It is used by a number of formats. > None of them matter to us for the forseeable future, except PEF. Yes. > ELF is implemented everywhere, except Windows and Mac (anyone know > what OS X uses?) And together that's 98% of the computers on the planet. All life is mammalian, except the 98% that's not. OS X uses GCC and Mach-O. I do not know much about its shared library system except that, like old-style MacOS, it seems really, really strange. > Since GCC is the one free compiler that we all have, and GCC makes > ELF, focusing on ELF makes sense. GCC makes other things, too. It makes ELF, COFF, X-COFF, Mach-O, a.out, even PEF. > Many/most of the OBOS kits will not be usable on R5's kernel for very > much longer, since we are quickly coming to the few points of impact where there are kernel issues. > This is not worth arguing over. > > Really. This has wasted more time than any of us can afford. PEF, > COFF, PE, etc are not realistic targets for OBOS, either now or in the forseeable future. I am sorry. OK. So there will be no OBOS patches for PPC, no beta testing to ensure endianness compatibility, nothing. Until the NewOS kernel is ported, all cross-platform compatibility issues will be avoided like the plague. All vision is limited to x86 and ELF. Right. I warn you, though, that things like endian independence *will* disappear if not tested, and you will face a *massive* reality shock come R1 time, and may never decide to leave x86 at all. Which, needless to say, is both blinkered and utterly idiotic. Let us consider what causes delays in coding. Is it (1) being required to actual invent algorithms and write the code, or (2) being required to do maintenance chores like adding function prototypes? Adding _EXPORT declarations, of course, falls in the second category, and requries almost no time. Only one is required per class or global function. That's not a lot of extra work, and if everyone did it, the cumulative effect on the OBOS R1 release date *might* cause it to ship up to 20 minutes late. Gosh. That's pretty unacceptable, huh? I'll bet that's less time than this entire discussion took. And the result? A PowerPC port that "just works". And, there, ladies and gentleman, is the end of any coding that I will be able to do for the OpenBeOS project "either now or in the foreseeable future" (other than the NewOS kernel, which needs a lot of work as it will not compile except with GCC, nor does it even work with the GCC included in OS X) since I am one of those hapless souls (and there are hundreds of us who use BeOS, btw), who happen to own all PowerPC hardware. -Nathan -- Fortune Cookie Says: The hearing ear is always found close to the speaking tongue, a custom whereof the memory of man runneth not howsomever to the contrary, nohow.