Except that maybe they'll be droping lots of API functions for Longhorn:

"Win32 has like 76,000 APIs, and they're taking it down to 8,000 with Longhorn technology," said one source familiar with the plans.

http://www.wininsider.com/news/comments.aspx?mid=4982





"Walter" <walter@digitalmars.com> wrote in message news:bochg4$1rtc$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bocged$1q8f$1@digitaldaemon.com...
> > Perhaps there should be a std.c.unix, containing all the "common" unix functionality, as well as std.c.linux, which has Linux-specific
variants.
>
> I could see an std.c.posix at some point.
>
> > There is an equivalent for Windows... some API's only existed on older
OS,
> > some only exist on newer OS.
>
> Microsoft may deprecate APIs, but they are still supported in all versions of win32. Perhaps you're thinking of win16 (which D doesn't support
anyway).
>
> > .NET is almost an entirely new platform!
>
> Yup. There will likely eventually be a std.dotnet.
>
>

I don't know how they plan to do that without breaking existing apps. If they do actually remove 90% of the APIs, then that would be essentially a quite different operating system, and so would merit a different package name entirely.

"Julio César Carrascal Urquijo" <adnoctum@phreaker.net> wrote in message news:boefio$1o8e$1@digitaldaemon.com...
> Except that maybe they'll be droping lots of API functions for Longhorn:
>
> "Win32 has like 76,000 APIs, and they're taking it down to 8,000 with Longhorn technology," said one source familiar with the plans.
>
> http://www.wininsider.com/news/comments.aspx?mid=4982
>
>
>
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:bochg4$1rtc$1@digitaldaemon.com...
> >
> > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bocged$1q8f$1@digitaldaemon.com...
> > > Perhaps there should be a std.c.unix, containing all the "common" unix functionality, as well as std.c.linux, which has Linux-specific
> variants.
> >
> > I could see an std.c.posix at some point.
> >
> > > There is an equivalent for Windows... some API's only existed on older
> OS,
> > > some only exist on newer OS.
> >
> > Microsoft may deprecate APIs, but they are still supported in all
versions
> > of win32. Perhaps you're thinking of win16 (which D doesn't support
> anyway).
> >
> > > .NET is almost an entirely new platform!
> >
> > Yup. There will likely eventually be a std.dotnet.
> >
> >
>
>

Walter wrote:

> It probably is 99% the same. One of the other problems I didn't mention,
> though, is the problem of updating it. Suppose D supports a dozen unix
> variants with the same module. I don't have access to all these variants. I
> update the module for abcunix, and inadvertently break xyzunix which does it
> differently.

That shouldn't really happen, if the functionality on std.c.posix is limited to the stuff that is in the Open Groups "Single UNIX Specification". After all, that's the document that defines what UNIX is. In fact, even Windows implements it through Cygwin, I believe.

The full contents of the specification is available online at: http://www.unix-systems.org/version3/online.html

> I'd rather have abcunix and xyzunix as separate modules, so that presumably
> whoever is updating xyzunix is doing it on an xyzunix box and won't be
> breaking any of the other unix support. Then, maintainers of each of the
> unix variants can fold/test the changes in when convenient.

This would only apply to the system specific parts, and I think everybody agrees that those really do belong in a different package.

Oh well. In the end I'm sure it'll work out fine. For the most part it already has. :-)

Elias

Why are there so many Unix variants?   Isn't there some sort of standard? ;)

Sean

"Walter" <walter@digitalmars.com> wrote in message news:boe8kj$1dpa$2@digitaldaemon.com...
> It probably is 99% the same. One of the other problems I didn't mention, though, is the problem of updating it. Suppose D supports a dozen unix variants with the same module. I don't have access to all these variants.
I
> update the module for abcunix, and inadvertently break xyzunix which does
it
> differently.
>
> I'd rather have abcunix and xyzunix as separate modules, so that
presumably
> whoever is updating xyzunix is doing it on an xyzunix box and won't be breaking any of the other unix support. Then, maintainers of each of the unix variants can fold/test the changes in when convenient.

Sean L. Palmer wrote:

> Why are there so many Unix variants?   Isn't there some sort of standard?
> ;)

Yes, there is. It's called the Single Unix Specification. It used to be called POSIX and is still usually referred to by that name. Hence the suggestion to put ann of the standard stuff in std.os.posix.

You can read all about it on http://www.opengroup.org/ or the more direct link: http://www.unix.org/. the standard itself can be found at: http://www.unix.org/version3/online.html

Elias

In article <bochg4$1rtc$1@digitaldaemon.com>, Walter says...
>
>
>"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bocged$1q8f$1@digitaldaemon.com...
>> Perhaps there should be a std.c.unix, containing all the "common" unix functionality, as well as std.c.linux, which has Linux-specific variants.
>
>I could see an std.c.posix at some point.

Hopefully sooner than later, then most people could use std.c.posix instead of std.c.linux, so in the future when D for SPARC/Solaris is released there will be minimal code changes.

Having lived through the UNIX "wars" of the late 1980's and early 1990's, I think it is better to start with a standard API and only deviate as necessary for a specific platform.

> >
> >I could see an std.c.posix at some point.
>

Well, I think there could be a std.c.posix that just do a public import of std.c.linux.