View previous topic :: View next topic |
Author |
Message |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Wed Sep 22, 2004 12:27 pm Post subject: Re: Win32 Headers |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Wed Sep 22, 2004 1:27 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Wed Sep 22, 2004 1:51 pm Post subject: Win32 |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Wed Sep 22, 2004 2:23 pm Post subject: Re: Win32 |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Wed Sep 22, 2004 2:52 pm Post subject: I am not a lawyer |
|
|
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](images/smiles/icon_smile.gif) _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Wed Sep 22, 2004 4:57 pm Post subject: Re: Win32 |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Thu Sep 23, 2004 1:12 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Fri Sep 24, 2004 5:41 am Post subject: |
|
|
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](images/smiles/icon_smile.gif) _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Fri Sep 24, 2004 9:05 am Post subject: |
|
|
What about std.utf? Doesn't Mango have its own version of those functions as well? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Sep 25, 2004 1:23 pm Post subject: |
|
|
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](images/smiles/icon_smile.gif) |
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](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Sat Sep 25, 2004 2:05 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Sat Sep 25, 2004 2:36 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
toaster
Joined: 03 Sep 2004 Posts: 7 Location: Lisbon
|
Posted: Mon Sep 27, 2004 4:38 pm Post subject: Re: Win32 Headers |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Sep 28, 2004 12:33 pm Post subject: Re: Win32 Headers |
|
|
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](images/smiles/icon_smile.gif) _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
toaster
Joined: 03 Sep 2004 Posts: 7 Location: Lisbon
|
Posted: Tue Sep 28, 2004 2:20 pm Post subject: Re: Win32 Headers |
|
|
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](images/smiles/icon_smile.gif) |
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 |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|