[Mono-devel-list] Mono.Posix OEE 0.6

Jonathan Pryor jonpryor at vt.edu
Thu Oct 21 21:20:14 EDT 2004

Mono.Posix Over-Engineered Edition 0.6.

This is (hopefully) the last version before it goes into CVS.

Major Changes since 0.5:
	- Enumeration name changes (CmdFlag -> FcntlCommand: it's not a 
	  flag, it's a single command, and it's only used by fcntl(2);
	  PosixFadviseFlags -> PosixFadviseAdvice: ditto - not flags,
	  but a "command".)
	- Correct some oversights (setgroups(2) wasn't properly wrapped)
	- Remove the "typedef structs".  At miguel's request, the 
	  underlying types are directly exposed -- ulong instead of 
	  size_t, etc.
	  Please, if you ever add new methods, if it contains platform-
	  specific data types (size_t, etc.), *please* provide a comment
	  with the original data type.  See Syscall.cs for examples.
	- Major make-map.exe re-write.  It's readable!  And it uses
	  classes!  Making it terribly over-engineered!
	- PosixUtils -> PosixMarshal.  The (sole) method in PosixUtils
	  (MarshalString) was conceptually the same as those exposed
	  by System.Runtime.InteropServices.Marshal, so PosixMarshal
	  made more sense (PosixUtils is teh suck).  Added some sensible
	  helper methods to simulate Marshal, such as Alloc, ReAlloc,
	  and Free.  Publicly exposed a way to marshal a char** into
	  a string[].

	  Mike Kestner: if  you're reading this, look at 
	  PosixMarshal.PtrToStringArray().  It's much cleaner than
	  GLib.Marshaller.ArrayPtrToArgv.  (No runtime 32/64-bit checks
	  and casting to int[]/long[].)

About the package

It has a makefile.  Unpack the archive, and build:

        $ tar xzf Mono-Posix-jp-0.4.tar.gz
        $ cd Mono.Posix-jp-0.4
        $ make

This will create a lot of .cs file, Mono.Posix.dll,
libMonoPosixHelper.so, and lots of test programs.

Main.exe is a badly cobbled test program, which calls stat(2) on all
command line arguments, printing out their information, and tries to
write "hello\n" to the file hello.txt using a PosixStream.

mls.exe is a "managed ls" -- it's there to test readdir(3) and co.

lsui.exe "lists user information" -- dumps out the passwd structure for
a user provided as a command-line argument.

lsgi.exe "lists group information" -- dumps out the group structure for
a group provided as a command-line argument.

I wrote this on Fedora Core 2, so if it doesn't compile on your system,
please let me know so I know what portability issues to fix.  Thanks to
Charlie Ford for letting me know about problems compiling on Red Hat 9. 
These should be corrected.


Remember that Mono.Posix-OEE uses the same names as the current
Mono.Posix.  Consequently, you'll have to set LD_LIBRARY_PATH (or
equivalent) to find the newer library, and you'll have to explicitly
link against OOE's Mono.Posix.dll.

About the Implementation

As mentioned previously, most functions are placed in Syscall, while C
standard library functions are in Stdlib.  In the interest of
"cuteness", Syscall derives from Stdlib, so all Stdlib methods are
present in Syscall (allowing you to use Syscall.free(), and permitting a
flat namespace which some have requested).

If you don't like this convention, *please* suggest a better one.  (One
header : One class wasn't liked by many, and Miguel doesn't seem to like
everything in Syscall, so I'm flying by ear here...)

Open Questions (more to follow, I'm sure):

I need some 64-bit OS advice.  Is it safe to assume (as I currently do)
that a 64-bit OS will provide the -64 API call?  I don't believe this is
actually safe, as open(2) and open64() should do the same thing on
64-bit platforms, so there isn't any need for open64() (except for

 - Jon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mono.Posix-OEE-0.6.tar.gz
Type: application/x-compressed-tar
Size: 43450 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20041021/92a76ea3/attachment.bin 

More information about the Mono-devel-list mailing list