[M3commit] CVS Update: cm3

[Jay]

(ps: except it stinks for cross building more fully; need those native C headers around....)


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Wed, 13 Feb 2008 11:26:42 +0000


Yes. I believe this is what I meant by "wrapping C in C". And my suggestion (since superceded) to wrap Utime global data with functions. For example my "get" functions for stdout/in/err. For example you would one stat struct, with just the fields anyone needs, with 64 bit sizes, with a unified time format (probably 64 bit seconds since Jan 1 1970).And then one C implementation, that #includes the native headers, and copies stuff over fairly portability, given the varying headers in scope. Or like how errno is. This is where more C code provides for more portability, since you are interfacing with code that is written in C (usually) and for which the "native" "interface language" is C headers. > It would not help much on Windows platforms of course :-/I have to again ask what is "Posix" and point out that "Windows" provides more than maybe people realize. There is open/read/write/lseek/close, very much like you are used to.Even pipe and fdopen. Even stat I think.You'd want to use lseeki64 though and co. Forward slashes work just fine in kernel32 functions (though aren't returned from GetFullPathName). And, if you only have one drive on your system, heck, just use path /foo/bar.m3 and it works. File.open dialogs unfortunately don't follow suit, very annoying to me. But there isn't native pthreads or native X Windows, or native select/poll, gettimeofday, granted. Some of this is doable with thin layering, sometimes thick.The Cygwin code is very complicated here.Vista adds "condition variables" and the "once" thingy and that probably would help a lot. The "native" time format is something like 100s of nanoseconds since jan 1 1601 in a 64 bit number of unclear signedness. There are a bunch of C runtime functions for dealing with 32 bit or 64 bit seconds since Jan 1 1970 though.(32 bit time_t..big problem...) opendir/readdir/closedir is pretty easy to implement upon FindFirstFile/FindNextFile, I've implemented them multiple times.. I'm not sure how much the network/socket apis are similar, I've never used them. mmap and CreateFile/CreateFileMapping/MapViewOfFile I suspect are a thin mapping layer apart. Hardlinks work fine on NTFS.Symlinks for directories, essentially, were introduced in Windows 2000 (again, NTFS).Symlinks for files and directories were introduced in Vista. They seem like a huge can of worms though. As do hard links.I see circularities.. File system ACLs and attributes (read only, hidden, executable), definitely variation there. I do think these systems are more similar than people acknowledge though.e.g. the usermode/kernelmode split. All "operating systems" except the lowest end (Mac/MS-DOS/Win3.1/Win9x) have been about the same design since about 1970...  - Jay

> Date: Tue, 12 Feb 2008 22:59:42 +0100> From: wagner at elegosoft.com> > I'm not sure that you are describing exactly was Jays intention was,> but as a general rule we should of course try to keep dependencies> on other languages or systems as few as possible in order to keep> portability and maintainability.> > That said, I always found that there are rather a lot of things> that are system dependent and need to be imported via a system-> specific interface. One idea to improve this situation was to> provide some generic POSIX interface layer which indeed does> some of the mappings and adaptations in C. This could be just enough> to get a base system up and running. I'm not sure how popular this> idea would be within the CM3 community, and it would be some tedious> work and need some refactoring of the code. It would make porting to> new POSIX platforms much easier of course.> > It would not help much on Windows platforms of course :-/> > Generally I'm not against refactoring and replacing code, but we> should have a good concept and reason to do it before we start.> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 

Helping your favorite cause is as easy as instant messaging. You IM, we give. Learn more. 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20080213/91587188/attachment-0002.html>