<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>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=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='_new'>Learn more.</a></body>
</html>