[$Header: /cvsroot/posix2/posix2/libext/FAQ,v 1.6 2000/05/02 16:19:55 amai Exp $]


	Frequently Asked Questions (FAQ) to the P/2 - libext project



				"Steve Jobs said two years ago that X is 
				brain-damaged and it will be gone in
				two years.  He was half right."
							 (Dennis Ritchie)


Q:
1.)
>I got libextensions. Can I replace all EMX headers with libextensions one? 

A:
Yes. They should be backwards compatible. Report any problems.
To put it more precisely: They should be backwards _source_ compatible. 

If you use our headers but _not_ use  our library, well, you know, a 
lot of exciting side effects are to be expected...  ;-)

Q:
2.)
>If yes, are you sure all will work ok?

A:
I'm absolutely (100%) sure and I will fully guarantee this, provided
you have already paid the full price for the libextensions
XXL-Super-Hyper-Software-Development-Kit. Price list on request.
(PS.: Will e-mail with a 10Mbyte price list bounce?)

3.)
>I successfully downloaded CVS of libextensions and was surprised not to
> see EMX in it at all.

We cannot merge libext and emx on the long run because of different
licenses. We will use a BSD-style license. 
Because of this we must cleanly separate both libraries. 

	In general, our goal is full compatibility with 4.4 BSD, 
to reuse as much 4.4 BSD Net/2 Release code as possible and to write
our own kernel interfaces from scratch. So please consider remaining
similarities to emx in _our_ code as being "fast'n dirty hacks" for
testing purposes, only.

4.)
>But why can't we integrate libextensions into EMX.

Because EMX is property of Eberhard Mattes and he has repeatedly
rejected - for several years now and not without good reasons - to
follow a route like our's. If he does not change his mind we will
respect his decision and must and _will_ leave emx untouched. This will
give you a choice: You can use the library interface _you_ need.

To make it absolutely clear: Our intention of seamless Un*x integration
on top of the OS/2 kernel is not any better or worse than emx's;
it's only different! And it is incompatible. This does _not_ mean that 
you cannot (and at this moment you even must do that) link against ANSI 
streams and other utility functions in the opaque emx dll's. It means: 

	We will not mix up the sources!

5.)
>I really do not want to mess with functions from different places and 
>want to keep them in 1 place ?

Yes, keep them in 1 place: libextensions. Help us to write a complete
and BSD compatible implementation. If you then specify 'gcc -lext' (_our_
library before emx libs) on the linker command line, all stat references
will be seamlessly resolved by _our_ library. Application programmers
even won't notice what is actually happening; they will only notice
that their Linux/SunOS/BSD sources now compile and run correctly. The
relevant emx functions in the dll will not be linked in. Please
remember: First specify, first resolve. And what has already been
resolved cannot be re-resolved.

6.)
>I get this when trying to compile the i387math module...
>
>i387math.s: Assembler messages: [...]
          ^^ Should not happen, we use a large 'S' here. 
Cf.:

GCC(1)                      GNU Tools                      GCC(1)


       .s    Assembler source; assemble
       .S    Assembler source; preprocess, assemble
       .h    Preprocessor file; not usually named on command line


  file.s 
            Assembler code. 

  file.S 
            Assembler code which must be preprocessed. 

  other 
            An object file to be fed straight into linking. Any file
name with no recognized suffix is treated this way.   
  
  You can specify the input language explicitly with the '-x' option:  


  -x language 
            Specify explicitly the language for the following input
files (rather than letting the compiler choose a default based 
            on the file name suffix).  This option applies to all
following input files until the next '-x' option.  Possible values 
            for language are: 
            
            c  objective-c  c++
            c-header  cpp-output  c++-cpp-output
            assembler  assembler-with-cpp


The Makefile has this rule:

  .S.o:
	  $(CC) $(CFLAGS) -c $< -o $@

Probably your make is broken and does mess up the rules. Try instead:

  %.o:	%.S
	  $(CC) $(CFLAGS) -c $< -o $@

or use x11make.exe from XFree86/2.

7.)
> - What is HRTIMER.SYS? Part of Warp Server? Or is it available somewhere?

Search Hobbes for hrtimr11.zip. It is a  device driver implementing a high
resolution timer. The author granted us the right to use, copy and modify his 
sources for our project and asks for giving him due credits in the docs.
See libext/test/usleep.c for detailed explanations.

8.)
> I want to submit patches. How to proceed.

Read docs/CodeRules.txt first! Then, first fix defective ASCII with fixtxt. 

In toplevel (CVSROOT) directory:

1) Run make distclean! 

2) cvs -z4 update

3) cvs -z4 diff -udw >diff.out

9.) I don't have a written documentation of the XYZ standard!

Well, unfortunately often standard documentations are sold -
probably to prevent the community from using them ;-)
We collect a growing list of links to "free" (i.e. no
cost, might require registration) programming&standard references:
  posix2/libext/Standards.html
A copy of this document should be on our website on SF

