Re: about lposix

["Mike Panetta" <panetta.mike@...>]

Yeah I just got done looking at the Windows API stuff on the microsft page.  I didn't realise just how different things really were.  Only thing I am worried about is if this library only handles the least common denominator (which seems to be windows, atleast in one of the cases you mention below) then the library will not truly solve the problem of different people going off and doing their own thing, because there are people out there that need the 'extra' features (like me, and I am very sure I am not the only one).  If we want to be able to have a library that can do all the stuff POSIX and windows can do, then we would need to have some sort of abstraction layer (which I think has been advocated here) but surly someone else has already done that (well there is cygwin but its 
1.2m like someone said, but of course maybe 1.2m isn't that big of a deal when programs on PC's are routinely 10-100x that large.) and I think it would be a waste of effort to re-invent the wheel.

The only thing I can do I tell you what I absolutly need the library to support...  Will this platform independant library give me these things?

1. The ability to fork and exec arbitrary processes off and wait (without blocking!) for them to finish executing, and give me an exit status from said process. (Getting the exit status from the process is VERY important in my application)

2. The ability to send arbitrary signals to said processes, including ones to kill or halt them if I deem that they have gone awry.

3. File/Directory manipulation.

4. IO Pipes between processes.  I routinely wrap unix utilities to redirect their output to an LCD (after some formatting) to tell the user whats happening on the system (IE fsck completion info)

Basicly I am using Lua as a replacement for some of the startup scripts, and a wrapper for several unix utilities in an embedded system.  I am also using it to toggle some IO to enable/disable bits of hardware on startup (but thats beyond the scope of this discussion).  I chose Lua because I wanted to have one single program I could run to access all these things (the Lua interpreter with added libraries) instead of a smattering of C based executables and shell scripts.  Lua seems perfect for this to me.  Lua is more then powerful enough to be used as a way to script system startup.  Infact I even toyed with the idea of writing a wrapper to libe2fs and writing my own e2fsck in Lua...  But thats just crazy :)

Mike

On 10/17/06, Doug Currie <doug.currie@gmail.com> wrote:

Tuesday, October 17, 2006, 7:03:04 PM, Natanael Copa wrote:

> The question is what posix funcs can't windows do, and then maybe do
> something special there. Is there a list of posix things windows can't
> do?

Superficially things look quite rosy; then you hit a brick wall. Off
the top of my head...

File descriptors in posix and HANDLES in Windows are not quite
equivalent. For example, select() in posix can use a file descriptor
to a file or socket, whereas in Windows only sockets work. There are
probably many similar issues with streams, standard I/O, process
handle inheritance, ownership, permissions, etc.

Symlinks are difficult. There have been attempts using NTFS reparse
points, but the semantics of these links differ from UNIX symlinks.
http://svn.haxx.se/dev/archive-2004-10/1023.shtml

Windows has a root directory and a current directory on each drive.
There is no single root directory "/"

Timers and time accounting are quite different. gettimeofday() can be
a real bear to emulate correctly; google for all the bug reports to
see what I mean.

Signals work much differently. Windows uses different mechanisms.

Windows threads are fine, but different from pthreads, e.g., no condition
variables.

The conformance page at
http://sourceware.org/pthreads-win32/conformance.html
will give you an idea of what's hard to do in the process/threads
area. sigwait() is not implemented, for example.

e

--
Doug Currie
Londonderry, NH