
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>(ps: except it stinks for cross building more fully; need those native C headers around....)<BR><BR><BR><BR><BR>

<BLOCKQUOTE>

<HR id=EC_stopSpelling>

From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3commit@elegosoft.com<BR>Subject: RE: [M3commit] CVS Update: cm3<BR>Date: Wed, 13 Feb 2008 11:26:42 +0000<BR><BR>

<META content="Microsoft SafeHTML" name=Generator>

<STYLE>

.ExternalClass .EC_hmmessage P

{padding:0px;}

.ExternalClass EC_body.hmmessage

{font-size:10pt;font-family:Tahoma;}

</STYLE>

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.<BR> <BR>For example my "get" functions for stdout/in/err.<BR> <BR>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).<BR>And then one C implementation, that #includes the native headers, and copies stuff over fairly portability, given the varying headers in scope.<BR> <BR>Or like how errno is.<BR> <BR>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.<BR> <BR>> It would not help much on Windows platforms of course :-/<BR><BR>I have to again ask what is "Posix" and point out that "Windows" provides more than maybe people realize.<BR> <BR>There is open/read/write/lseek/close, <EM>very </EM>much like you are used to.<BR>Even pipe and fdopen. Even stat I think.<BR>You'd want to use lseeki64 though and co.<BR> <BR>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.<BR> <BR>But there isn't native pthreads or native X Windows, or native select/poll, gettimeofday, granted.<BR> <BR>Some of this is doable with thin layering, sometimes thick.<BR>The Cygwin code is very complicated here.<BR>Vista adds "condition variables" and the "once" thingy and that probably would help a lot.<BR> <BR>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.<BR>(32 bit time_t..big problem...)<BR> <BR>opendir/readdir/closedir is pretty easy to implement upon FindFirstFile/FindNextFile, I've implemented them multiple times..<BR> <BR>I'm not sure how much the network/socket apis are similar, I've never used them.<BR> <BR>mmap and CreateFile/CreateFileMapping/MapViewOfFile I suspect are a thin mapping layer apart.<BR> <BR>Hardlinks work fine on NTFS.<BR>Symlinks for directories, essentially, were introduced in Windows 2000 (again, NTFS).<BR>Symlinks for files and directories were introduced in Vista. They seem like a huge can of worms though. As do hard links.<BR>I see circularities..<BR> <BR>File system ACLs and attributes (read only, hidden, executable), definitely variation there.<BR> <BR>I do think these systems are more similar than people acknowledge though.<BR>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...<BR> <BR> - Jay<BR><BR>

<HR id=EC_stopSpelling>

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

<HR>

Helping your favorite cause is as easy as instant messaging. You IM, we give. <A href="http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join" target=_blank>Learn more.</A> </BLOCKQUOTE><br /><hr />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>

</html>