September 18, 2004
Helmut Leitner wrote:
> 
> Mark T wrote:
> 
>>In article <414A7C9E.543F83BF@wikiservice.at>, Helmut Leitner says...
>>
>>>And, of course:
>>>
>>>  std.c.windows.windows.d
>>>
>>>should go from about 10% to at least 95% coverage of the Win32 API.

I agree with this, but I think there'd be too much code for one file (windows.d is already huge as it is). It should be split into multiple modules:

std.c.windows.commdlg
std.c.windows.ole2
std.c.windows.oleauto
std.c.windows.oleextra
std.c.windows.winbase
std.c.windows.windef
std.c.windows.wingdi
std.c.windows.winnt
std.c.windows.winuser
std.c.windows.wtypes

>>
>>Why should the standard language have a complete map to the Win32 API?
>>This should really be in its own module.
> 
> 
>    (1) because you get thousands of collission problems otherwise

The collisions can be very annoying, but there are solutions -- even without Walter's direct help.


Two methods that I've seen:

1) Standalone: don't use std.c.windows.windows and its buddies in Phobos

2) Complimentary: leave out the sections in the extra headers that are already in Phobos


There are already a couple projects aim to be suitable ports of the Win32 headers: Core32 and Y. Tomino's project.


Core32
http://dsource.org/projects/core32/

The idea behind the Core32 project is to allow either method. Method 2 is used by default, but Method 1 can be used by compiling in the version(STANDALONE) code.

I'm currently using Core32, and I have write access to the SVN repository. Many of the version(STANDALONE) locations have been added based on trial-and-error. I fix 'em when I find 'em.


Y. Tomino's project
http://hp.vector.co.jp/authors/VA028375/d/windows.h.html

This project only uses Method 1. I've used this code in the past. It's a solid port, too.



-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
September 18, 2004
I have one suggestion, that I know you more than likely wont adopt.

That is, you pluck about half a dozen of the very talented
people on this NG(these would more than likely be the ones that are
frustrated), and utilize their talents.
Give them each a particular task that you want done, whether it be a bug fix
or enhancement, when they complete it you can take a look. If you are happy,
then you can repeat the process.....

Im sure those talented people would be honored to be involved, and you could still be in control.

Otherwise you just might end up having to post this same message again in 6 months time.

You arent superman, no offense intended(probably a lot taken).

Phill

 "Walter" <newshound@digitalmars.com> wrote in message
news:cht9gl$20m8$1@digitaldaemon.com...
> In some delightful ways, D is a victim of its own success. There's a lot
of
> traffic in the D newsgroups, sometimes getting to 100 messages per day.
Not
> a day goes by without new proposals for features. It's simply beyond my capacity to give these all the attention they deserve, or even to read
them
> all. I probably spend a minimum of 2 hours a day reading messages, and I could easilly spend 12 hours a day at it, and accomplish nothing else.
>
> Hence, I inadvertently overlook important issues. I know that this has
been
> frustrating to some people, and I apologize for it.
>
> So I'd like to kick off this thread as an opportunity for all to post
their
> two Most Important Issues for D with respect to getting 1.0 done. By MIID,
I
> mean pragmatic things like:
>
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or
proceeding
> with D
> 4) severe library faults
>
> I don't mean things like:
>
> 1) D 2.0 issues
> 2) feature proposals like "It would be nice if ..."
> 3) minor irritants
> 4) philosophical issues
> 5) issues that have been beaten to death already <g>
>
> If a thread here exists for the topic, a reference to that thread would be nice rather than reproducing it.
>
> It's time to prioritize and get us on a rational, sensible path for releasing 1.0.
>
>


September 18, 2004
Hehe, can you say , cha-ching!
Charlie

In article <cieto4$1m33$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <cies8m$1iqg$1@digitaldaemon.com>, Mark T says...
>>
>>Maybe a separate win32.d module could contain the complete API. If Billy G has his way Win32 will become obsolete anyways.
>
>As well the .NET windowing API.  Sometimes it seems MS deprecates stuff before it's even shipped ;)
>
>
>Sean
>
>


September 20, 2004
DEBUGGING OH MY GOD DEBUGGING!

Everything else I've seen in this thread is incredibly minor in the face of being able to easily debug a program!  I think only one other person mentioned it.

Until I can just fire up a debugger and see into data structures, D is sadly not really usuable in my projects, as I want to build products more than fight with stupid watch expressions just to look inside a struct.

Please oh please don't make me go back to C++ and/or perl!  Please get real debugging support in here!

(This issue should be filed under "3) issues that are fundamentally blocking
projects from using or proceeding with D".)


September 20, 2004

Berin Loritsch wrote:
> 
> Helmut Leitner wrote:
> >
> > Mark T wrote:
> >
> >>In article <414A7C9E.543F83BF@wikiservice.at>, Helmut Leitner says...
> >>
> >>>And, of course:
> >>>
> >>>  std.c.windows.windows.d
> >>>
> >>>should go from about 10% to at least 95% coverage of the Win32 API.
> >>
> >>Why should the standard language have a complete map to the Win32 API? This should really be in its own module.
> >
> >
> >    (1) because you get thousands of collission problems otherwise
>
> ?? Huh?  A little more detail please?

As I said: it's way too inefficient to define the API on demand, so users will expect the Win32 API predefined. If (Phobos)windows.d isn't complete (but anyone will still build on it) you will combine another module for the rest. The chance is extremely high that there is an overlap that will lead to collisions. This will bite nearly everyone doing Win32, especially those building fundamental modules.

> >    (2) D will never be a success if it doesn't support Windows out of the box
> 
> I suppose there is noone using other operating systems out there then?  How much of a success does D have to be before it is good to write software in?

I don't understand your question. It's a question of efficiency.

> You can support windows without mapping the whole win32 API.  I don't know about you, but I found writing MFC code bad enough--whenever I even attempted to look at win32 code it gave me a headache.  As long as there is a windowing/gui toolkit (several are under development), and standard libraries to do your I/O work then those libraries can map to whatever API is available.  The bottom line is to start reasonably then build on that.  The entire win32 API is quite large and it covers everything from windowing to threads to socket IO to file IO to driver communications. Not to mention the hacked POSIX half-support.  Do you really want to bloat the D API with all that nastiness?

No, but there will be those that build the D-GUI APIs.
And Win32 is the last resort if you need to do special things.

MFC is built as a C++ wrapper for the Win32.
We will not get good D wrappers if it is a lot of nasty work
to accesss the Win32 API.

> >>Maybe a separate win32.d module could contain the complete API.
> >
> >
> >    collission problems.
> 
> Info?  Supporting information would help.  WHat do you mean "collision problems"?
> 
> >>If Billy G has his way Win32 will become obsolete anyways.
> >
> >
> >    It won't, for
> >      (1) it's at the basis of so many application
> >      (2) the .NET -> Win32 Interface is just as broken and
> >          slow as the Java native code interface to Windows
> 
> You lost me.  Yes, the first argument is the only one that makes sense here.  They would be quite foolish to simply remove it and render the current investment in software null and void.  MS would lose their shirt because noone would want to upgrade.
> 
> When you say Win32 API just what part are you talking about?
> If you are merely limiting it to the GUI related API then I would
> agree that the Java API (built in and for Java) is slower than
> many C++ programs, but if you know how to work with it instead of
> against it, then it is fast enough.

Fast enough is sometimes not enough. Last time I tested,  JNI and .NET
had the same API call overhead of about 40 usec (950 MHz Athlon).
This may not seem much, but it is the equvalent to about 200 simple
C function calls for a one API call. So, forget about high performance
timing and pixel io.

D doesn't have this overhead!

The Win32 API isn't that bad if you are used to it. A lightweight wrapper for application building and menus / MDI would be enough if the access to the other Win32 functions is easy.

I argue that it should be easy for at least 95% of Win32.
Things needn't be perfect. But usable.

> Don't be in such tunnel vision to assume that the world is Windows. To tell the truth, there is a lot of potential for D outside the world of Windows

Cool down, I know that very well. I live in both worlds. Still a large part of the world is Windows.

> --if the debugging information can get straightened
> out.  If it's a pain to find what's wrong in your programs then
> noone will use it.

I'm sure that Walter will work that out. This is just work, not a problem.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
September 20, 2004
"Stephen Silber" <Stephen_member@pathlink.com> wrote in message news:cil97f$1nn0$1@digitaldaemon.com...
>
> DEBUGGING OH MY GOD DEBUGGING!

I heard you <g>!


September 21, 2004
"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ci3jv1$10v8$1@digitaldaemon.com...
> (1) Suppose a class A has its own custom allocator/deallocator. Suppose it
also
> has a destructor. I want to be able to call the destructor (~this())
/without/
> also calling the deallocator. I also want to be able to call the
deallocator
> (the delete override) /without/ also calling the destructor. Both of these things are possible in C++, but not in D. Same goes for allocation versus construction.

> (2) I want to be able to globally (not just per-class) override new. For
> example, I want to be able to do:
>
> #    int[] array = new(myGlobalAllocator) array[n];

You can do:
    int[] array = (cast(int*)myGlobalAllocator(n * int.sizeof))[0..n];



> (3) And (most importantly) I want the garbage collector's memory-tracking
> mechanism to /notify me/ when the memory I've allocated via my custom
allocator
> is no longer referenced.

That's what the destructor is for. But perhaps I'm misunderstanding you - do you mean having a custom allocator work with the existing gc? I don't know how that would work.


> With these modifications in place, all memory allocation issues, including garbage collection across DLL boundaries; plugging in an alternative
garbage
> collector; secure wiping of sensitive data; super-fast
allocation/deallocation
> of small objects; etc., would become immediately and simply solvable.

You can already plug in a different gc - the API for it is simple - but it isn't so easy to write one. But I don't think that's what you mean. I think I understand what you're driving at, but I don't think it is easy to achieve :-(


September 22, 2004
In article <ciq19h$28dr$1@digitaldaemon.com>, Walter says...

>> (2) I want to be able to globally (not just per-class) override new. For
>> example, I want to be able to do:
>>
>> #    int[] array = new(myGlobalAllocator) array[n];
>
>You can do:
>    int[] array = (cast(int*)myGlobalAllocator(n * int.sizeof))[0..n];

That's not really very impressive though. It's no more advantageous than a simple function/functor. It achieves no more than:

#    int[] array = cast(int*)myMalloc(n*int.sizeof);

only with more typing.


Anyway - if you follow this thread, note that I actually changed my mind about this being a most important issue. In the end, I voted instead for complete debugging information.



>You can already plug in a different gc - the API for it is simple - but it isn't so easy to write one. But I don't think that's what you mean. I think I understand what you're driving at, but I don't think it is easy to achieve :-(

It's not urgently important. Maybe when we're both not so busy (!) I'll mention what I'm going on about in more detail and in a different thread. If you could prioritise the debugging thing over this, that'd be great.

Many thanks for D, and its continuing improvement.
Jill


September 22, 2004
In article <cir7m9$1imj$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <ciq19h$28dr$1@digitaldaemon.com>, Walter says...
>
>>> (2) I want to be able to globally (not just per-class) override new. For
>>> example, I want to be able to do:
>>>
>>> #    int[] array = new(myGlobalAllocator) array[n];
>>
>>You can do:
>>    int[] array = (cast(int*)myGlobalAllocator(n * int.sizeof))[0..n];
>
>That's not really very impressive though. It's no more advantageous than a simple function/functor. It achieves no more than:
>
>#    int[] array = cast(int*)myMalloc(n*int.sizeof);
>
>only with more typing.

Placement new would be nice.  A quick scan of the docs doesn't seem to imply this exists.  But it's not in my top 5 list of needed things.


Sean


September 24, 2004
Stewart Gordon schrieb:

> BUDI ARIEF GUSANDI wrote:
> <snip>
> 
>> 1. D can only run on Windows Console, i can not run it in pure DOS  Console.
> 
> 
> Yes, because MS-DOS is a 16-bit system.  D needs at least a 32-bit system, by design.

Someone got some DMD-made code work on DOS using a 32-bit DOS-extender, if i recall correctly.

>> This is is something very important since C and C++ can do that.

Using advanced C++ on a 16-bit system looks like trouble to me, due to 64 kilobytes allocation unit maximum.

GCC doesn't work on 16-bit systems either, yet there is DJGPP (using an extender), so if there is a recent DJGPP update, combining it with GDC would get you a DOS-compatible D compiler.

>> How can i run it on embedded system if it should require windows ?

You can make it run under just about any 32-bit operating system, DOS extender being no exception.

About the executable size: it comes from the basic libraries. You would need to rework them for an embedded system anyway, and i'm sure one can  make the problem go away with it.

On the other hand, i recall DJGPP generated executables were quite big, however the extender removes code size restrictions so you need not care any longer. :>

-eye