FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Beginnings
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Wed Sep 22, 2004 12:27 pm    Post subject: Re: Win32 Headers Reply with quote

jcc7 wrote:

My basis thesis is: std.c.windows.windows is already a fairly large file (78 kb) and my guess is that it doesn't even contain 50? of the definitions that it should have. I'm basing my guess by looking at the sizes of winbase.d (114 kb), winuser (134 kb), wingdi (123 kb), winnt (134 kb), etc, in the Core32 project. There might be some wasted space in Core32, but not that much. If we keep it all in one file, it's going to get huge. Microsoft doesn't keep them all in one file, why should we?


Sweet. Thanks for the info. I'd love to see that become the windows tree in Ares. I suppose that other OS-specific APIs? would follow suit?

I haven't used core32 at all, but the activity on the board suggests that its pretty stable. Can anyone comment on this?
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
qbert



Joined: 30 Mar 2004
Posts: 209
Location: Dallas, Texas

PostPosted: Wed Sep 22, 2004 1:27 pm    Post subject: Reply with quote

Layout looks good to me, I agree that win32 needs to be broken up.

Haven't used Core32, but YT's translations have all win32 + com stuff, ive used it alot and haven't found any mistakes, Im up for voting either core32 or YT's as a replacement for whats in phobos now.

Charlie
Back to top
View user's profile Send private message MSN Messenger
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Wed Sep 22, 2004 1:51 pm    Post subject: Win32 Reply with quote

qbert wrote:
Im up for voting either core32 or YT's as a replacement for whats in phobos now.
I've had success using YT's port, too. It may even be better than Core32 since so much of it is produced through automation.

Not to rain on the parade, but I do wonder if we need to worry about legal implications of these statements (as found in Core32):
Code:
Copyright (c) 1990-1996, Microsoft Corp. All rights reserved.
How does Walter work around the copyright issue? How did the Wine Project come up with GPLed Windows headers? I don't want to "infect" the new Ares project with uncertain IP issues.
Back to top
View user's profile Send private message AIM Address
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Wed Sep 22, 2004 2:23 pm    Post subject: Re: Win32 Reply with quote

jcc7 wrote:
How did the Wine Project come up with GPLed Windows headers? I don't want to "infect" the new Ares project with uncertain IP issues.


I know that MinGW follows these rule(s) (free from memory):

No headers are direct or indirect copies of the originals.
The only thing to be considered as known prior to 'implementing' the header files was/is the symbol names. Their values and such had to be found 'accidently' through trial and error.

These headers are used in other projects like Open Watcom. I believe their license is as free as possible.
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Wed Sep 22, 2004 2:52 pm    Post subject: I am not a lawyer Reply with quote

Well, we'd have to double-check some prior art of some kind to be sure everyone involved is within their right to strip that copyright out of the file.

Are there any commercial, non-C-like languages that are still linkable against win32 binaries? I think one could make a good case of the fact that simply "building your own" interface to win32 in a different language is sufficent enough to make it divergent from the original (and hence not MS's work).

Off the top of my head, I'd have to say that core32 probably has the right idea, as they simply translated the original headers over to D. I also wouldn't expect MS to be able to say "all your Ares are belong to us". Smile
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Wed Sep 22, 2004 4:57 pm    Post subject: Re: Win32 Reply with quote

larsivi wrote:
I know that MinGW follows these rule(s) (free from memory):

No headers are direct or indirect copies of the originals.
The only thing to be considered as known prior to 'implementing' the header files was/is the symbol names. Their values and such had to be found 'accidently' through trial and error.

These headers are used in other projects like Open Watcom. I believe their license is as free as possible.
Thanks for the tip. Apparently, MinGW is mostly "public domain" (which is definitely cool). I wonder how well YT's conversion script would run on it...
Back to top
View user's profile Send private message AIM Address
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Thu Sep 23, 2004 1:12 pm    Post subject: Reply with quote

Some further thoughts (I just got myself a job (for some time at least), so I'm sucking up quite a lot there at the moment. I'll try to contribute in small amounts, still.)

std.ctype should be renamed to std.type.ascii and get real names (not those all-lower-case-stuff)

std.file should possibly use upper-case-letters more (more verbose names?).

std.math should definately be more verbose in it's function names (C function names are out of date IMO).

std.path, std.process and std.string has the same symptoms
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Fri Sep 24, 2004 5:41 am    Post subject: Reply with quote

larsivi wrote:
Some further thoughts (I just got myself a job (for some time at least), so I'm sucking up quite a lot there at the moment. I'll try to contribute in small amounts, still.)

std.ctype should be renamed to std.type.ascii and get real names (not those all-lower-case-stuff)

std.file should possibly use upper-case-letters more (more verbose names?).

std.math should definately be more verbose in it's function names (C function names are out of date IMO).

std.path, std.process and std.string has the same symptoms


All good points. Are you advocating that we keep std.file and std.path? I think the current plan is to roll these two under the bus along with std.stdio and replace it all with a rendition of mango.io in the std.io tree. Smile
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Fri Sep 24, 2004 9:05 am    Post subject: Reply with quote

What about std.utf? Doesn't Mango have its own version of those functions as well?
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Sep 25, 2004 1:23 pm    Post subject: Reply with quote

pragma wrote:
All good points. Are you advocating that we keep std.file and std.path?


Eh, no.

pragma wrote:
I think the current plan is to roll these two under the bus along with std.stdio and replace it all with a rendition of mango.io in the std.io tree. Smile


I use IO stuff far too little to have an opinion here. Since this would be a major change, I think we should have a major discussion first, that is get all the pros and cons of both std.stdio and friends and mango.io (and others). We (at least I) need a specification over what's needed before we (that is I) can make a qualified choice over what's going into a standard lib. Mango is an io-centric library and therefore possibly overqualified for the task (although it is most likely perfect, kris seems like he knows the subject).

Well, I'll vote for mango.io until someone convince me othervise. (or I might vote blank) Smile
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Sat Sep 25, 2004 2:05 pm    Post subject: Reply with quote

Just for the sake of comparison, check out my rewrite of std.stream. It's just a proof of concept (and missing some notable features), but addresses some basic design issues that I found lacking in std.stream.

That said, I think Mango.io is more flexible and it may well have my vote also. But I don't want to forego discussion just because it's more complete.

But this is getting a bit ahead of ourselves. I'd like to see some basic functionality before dealing with such a large issue as streams. At the very least, we'll need to be able to do utf conversions to do formatted i/o.
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Sep 25, 2004 2:36 pm    Post subject: Reply with quote

sean wrote:
But this is getting a bit ahead of ourselves. I'd like to see some basic functionality before dealing with such a large issue as streams. At the very least, we'll need to be able to do utf conversions to do formatted i/o.


Yes, I think Unicode support should be the first area to focus our forces on. Much of the rest might be delegated, but this is to basic and to important. A new thread on the subject should be opened. Posts from the opening discussions around Ares should be referenced at the top.
Back to top
View user's profile Send private message
toaster



Joined: 03 Sep 2004
Posts: 7
Location: Lisbon

PostPosted: Mon Sep 27, 2004 4:38 pm    Post subject: Re: Win32 Headers Reply with quote

pragma wrote:

My basis thesis is: std.c.windows.windows is already a fairly large file (78 kb) and my guess is that it doesn't even contain 50? of the definitions that it should have. I'm basing my guess by looking at the sizes of winbase.d (114 kb), winuser (134 kb), wingdi (123 kb), winnt (134 kb), etc, in the Core32 project. There might be some wasted space in Core32, but not that much. If we keep it all in one file, it's going to get huge. Microsoft doesn't keep them all in one file, why should we?


I don't know if this helps but you can separate file contents from externally visible namespace by doing the following:

divide std.c.windows.windows in several smaller files like
std.c.windows.windows_a
std.c.windows.windows_b
std.c.windows.windows_c

Then, in the file std.c.windows.windows you write:

Code:

import std.c.windows.windows_a;
import std.c.windows.windows_b;
import std.c.windows.windows_c;


public alias std.c.windows.windows_a.foo foo;
public alias std.c.windows.windows_a.bar bar;
public alias std.c.windows.windows_b.foobar foobar;
public alias std.c.windows.windows_c.barfoo barfoo;


Now, a file that imports std.c.windows.windows can reference the functions in the subfiles by std.c.windows.windows.foo etc
The original name (std.c.windows.windows_a.foo) gets shadowed and is not acessible. At least this is the behaviour of my current version of the dmd compiler.

This can provide shorter files all behaving (from an external point of view) like the same module, so it's easier to write and maintain (I HATE my 2500 line files when I have to scroll between something in the top and something in the bottom don't you?).

Maybe everybody but me already knew this, but if so, since I am using this in my own code, please could somebody warn me if this is considered bad practice?
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Sep 28, 2004 12:33 pm    Post subject: Re: Win32 Headers Reply with quote

toaster wrote:

Maybe everybody but me already knew this, but if so, since I am using this in my own code, please could somebody warn me if this is considered bad practice?


Generally speaking, this is a Very Bad Thing(tm). What you are doing is splitting a large API across arbitrary boundaries into separate files. Those files, in turn, have little more meaning than the parent file yet fail to describe their contents by much more.

The problem comes down to use and maintainability. If I were looking to see that SetWndProcA also had a unicode sibling (SetWndProcW) where would I look? Now, were there a file that had a name outlining a purpose similar to what I was looking for, then I could start there instead of hunting through a, b ,c and then d.

Another way to look at this is for consistency: I'd expect string functions to be in "std.string" and I'd also expect a string class (if there is one) to be called "String".. not class "X" in "std.A". As your classes are named purposefully, so should your packages and sub packages. Smile
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
toaster



Joined: 03 Sep 2004
Posts: 7
Location: Lisbon

PostPosted: Tue Sep 28, 2004 2:20 pm    Post subject: Re: Win32 Headers Reply with quote

pragma wrote:
toaster wrote:

Maybe everybody but me already knew this, but if so, since I am using this in my own code, please could somebody warn me if this is considered bad practice?


Generally speaking, this is a Very Bad Thing(tm). What you are doing is splitting a large API across arbitrary boundaries into separate files. Those files, in turn, have little more meaning than the parent file yet fail to describe their contents by much more.

The problem comes down to use and maintainability. If I were looking to see that SetWndProcA also had a unicode sibling (SetWndProcW) where would I look? Now, were there a file that had a name outlining a purpose similar to what I was looking for, then I could start there instead of hunting through a, b ,c and then d.

Another way to look at this is for consistency: I'd expect string functions to be in "std.string" and I'd also expect a string class (if there is one) to be called "String".. not class "X" in "std.A". As your classes are named purposefully, so should your packages and sub packages. Smile


Yes you are right, I wasn't thinking of the size of that API. As a matter in fact, i am complaining about having to scroll in big files, and to fix it I would propose to have more files, so I would have to scroll AND to switch between files ... looks like a Bad Ideia(tm).

My usage is different, i just split three huge classes into three files (they are named after the classes, so searching is not an issue), but I want to appear them (from outside) to be in the same module. So I am aliasing three classes, not hundrets of functions.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group