Matthew wrote:

>>>>That was my first approach. But I think it is unnecessary, one only
>>>>        
>>>>
>>needs
>>    
>>
>>>to
>>>      
>>>
>>>>check GetVersion() for 95, 98, and ME. This is because the lack of
>>>>        
>>>>
>>support
>>    
>>
>>>>is confined to 95, 98 and ME, and since they are officially abandoned
>>>>        
>>>>
>by
>  
>
>>>>Microsoft, it will never get fixed.
>>>>        
>>>>
>>>That's true for the A vs W issue, but there are also API functions that
>>>      
>>>
>>are
>>    
>>
>>>added as the OSs, and even the Service Packs, progress.
>>>      
>>>
>>In general, I'd prefer to rely on failure indications rather than version
>>numbers to check for features. But my experience with that with the win32
>>API has been rather negative, the failure indications are unreliable. For
>>example, the 'copy-on-write' for memory mapped files is not implemented on
>>Win95, but the API, instead of failing, silently converts it to 'write'.
>>    
>>
>
>Indeed. All this argues for a win32 layer, but I think several people have
>already questioned whether it is better as a separate library rather than in
>the language. I'm still in two (or three) minds about the whole issue. :(
>
>
>  
>
Parhaps users could specify what OS type they wish to compile for. ie

pragma (Win95)

pragma (Hibrid) //Any

pragma (WinNT)

ect...

That way they can be certain that it'll compile for that OS. Any problem functions would cause an error in the compiler.  Only problem is that you need to know which ones have the errors.

J Anderson wrote:

> Matthew wrote:
>
>>>>> That was my first approach. But I think it is unnecessary, one only
>>>>>       
>>>>
>>> needs
>>>   
>>>
>>>> to
>>>>     
>>>>
>>>>> check GetVersion() for 95, 98, and ME. This is because the lack of
>>>>>       
>>>>
>>> support
>>>   
>>>
>>>>> is confined to 95, 98 and ME, and since they are officially abandoned
>>>>>       
>>>>
>> by
>>  
>>
>>>>> Microsoft, it will never get fixed.
>>>>>       
>>>>
>>>> That's true for the A vs W issue, but there are also API functions that
>>>>     
>>>
>>> are
>>>   
>>>
>>>> added as the OSs, and even the Service Packs, progress.
>>>>     
>>>
>>> In general, I'd prefer to rely on failure indications rather than version
>>> numbers to check for features. But my experience with that with the win32
>>> API has been rather negative, the failure indications are unreliable. For
>>> example, the 'copy-on-write' for memory mapped files is not implemented on
>>> Win95, but the API, instead of failing, silently converts it to 'write'.
>>>   
>>
>>
>> Indeed. All this argues for a win32 layer, but I think several people have
>> already questioned whether it is better as a separate library rather than in
>> the language. I'm still in two (or three) minds about the whole issue. :(
>>
>>
>>  
>>
> Parhaps users could specify what OS type they wish to compile for. ie
>
> pragma (Win95)
>
> pragma (Hibrid) //Any
>
> pragma (WinNT)
>
> ect...
>
> That way they can be certain that it'll compile for that OS. Any problem functions would cause an error in the compiler.  Only problem is that you need to know which ones have the errors.
>
I should add that problem functions could be coded something-like-this to report errors.

Version (Win95)
{     CreateFileW(...)
   {
      static_assert("W Functions not supported in win95.");
   }

)
else if (Hybrid)
{
  //Some solution that works for both win95 and winNT
}
else
{
  export CreateFileW(...); //Normal

}

Programmers wouldn't be able to use the function in a win95 product, but at least they know it won't work.

Anderson

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:btvqnr$ql9$1@digitaldaemon.com...
> J Anderson wrote:
>
> > Matthew wrote:
> >
> >>>>> That was my first approach. But I think it is unnecessary, one only
> >>>>>
> >>>>
> >>> needs
> >>>
> >>>
> >>>> to
> >>>>
> >>>>
> >>>>> check GetVersion() for 95, 98, and ME. This is because the lack of
> >>>>>
> >>>>
> >>> support
> >>>
> >>>
> >>>>> is confined to 95, 98 and ME, and since they are officially
abandoned
> >>>>>
> >>>>
> >> by
> >>
> >>
> >>>>> Microsoft, it will never get fixed.
> >>>>>
> >>>>
> >>>> That's true for the A vs W issue, but there are also API functions that
> >>>>
> >>>
> >>> are
> >>>
> >>>
> >>>> added as the OSs, and even the Service Packs, progress.
> >>>>
> >>>
> >>> In general, I'd prefer to rely on failure indications rather than
> >>> version
> >>> numbers to check for features. But my experience with that with the
> >>> win32
> >>> API has been rather negative, the failure indications are
> >>> unreliable. For
> >>> example, the 'copy-on-write' for memory mapped files is not
> >>> implemented on
> >>> Win95, but the API, instead of failing, silently converts it to
> >>> 'write'.
> >>>
> >>
> >>
> >> Indeed. All this argues for a win32 layer, but I think several people
> >> have
> >> already questioned whether it is better as a separate library rather
> >> than in
> >> the language. I'm still in two (or three) minds about the whole
> >> issue. :(
> >>
> >>
> >>
> >>
> > Parhaps users could specify what OS type they wish to compile for. ie
> >
> > pragma (Win95)
> >
> > pragma (Hibrid) //Any
> >
> > pragma (WinNT)
> >
> > ect...
> >
> > That way they can be certain that it'll compile for that OS. Any problem functions would cause an error in the compiler.  Only problem is that you need to know which ones have the errors.
> >
> I should add that problem functions could be coded something-like-this to report errors.
>
> Version (Win95)
> {
>     CreateFileW(...)
>     {
>        static_assert("W Functions not supported in win95.");
>     }
>
> )
> else if (Hybrid)
> {
>    //Some solution that works for both win95 and winNT
> }
> else
> {
>    export CreateFileW(...); //Normal
>
> }
>
> Programmers wouldn't be able to use the function in a win95 product, but at least they know it won't work.
>
> Anderson

I think you have the nexus of a good strategy here. The only challenge is not to have to build in a load of Win-specific stuff to the compiler or, heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new people who are complaining about writing Win32 code in D. I think that, even though it's Win32's problem not D's, D will still be deemed painful if it does not address these issues. We should remember that .NET handles all this filth, and Java obviates the discussion by disallowing interaction with the Win32 (or any other) API. The bulk of people coming to D from that background will be peed off to be met with all these hidden nasties.

Matthew wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:btvqnr$ql9$1@digitaldaemon.com...
>  
>
>>J Anderson wrote:
>>
>>    
>>
>>>Matthew wrote:
>>>
>>>      
>>>
>>>>>>>That was my first approach. But I think it is unnecessary, one only
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>needs
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>to
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>check GetVersion() for 95, 98, and ME. This is because the lack of
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>support
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>is confined to 95, 98 and ME, and since they are officially
>>>>>>>              
>>>>>>>
>abandoned
>  
>
>>>>by
>>>>
>>>>
>>>>        
>>>>
>>>>>>>Microsoft, it will never get fixed.
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>That's true for the A vs W issue, but there are also API functions
>>>>>>that
>>>>>>
>>>>>>            
>>>>>>
>>>>>are
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>added as the OSs, and even the Service Packs, progress.
>>>>>>
>>>>>>            
>>>>>>
>>>>>In general, I'd prefer to rely on failure indications rather than
>>>>>version
>>>>>numbers to check for features. But my experience with that with the
>>>>>win32
>>>>>API has been rather negative, the failure indications are
>>>>>unreliable. For
>>>>>example, the 'copy-on-write' for memory mapped files is not
>>>>>implemented on
>>>>>Win95, but the API, instead of failing, silently converts it to
>>>>>'write'.
>>>>>
>>>>>          
>>>>>
>>>>Indeed. All this argues for a win32 layer, but I think several people
>>>>have
>>>>already questioned whether it is better as a separate library rather
>>>>than in
>>>>the language. I'm still in two (or three) minds about the whole
>>>>issue. :(
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>Parhaps users could specify what OS type they wish to compile for. ie
>>>
>>>pragma (Win95)
>>>
>>>pragma (Hibrid) //Any
>>>
>>>pragma (WinNT)
>>>
>>>ect...
>>>
>>>That way they can be certain that it'll compile for that OS. Any
>>>problem functions would cause an error in the compiler.  Only problem
>>>is that you need to know which ones have the errors.
>>>
>>>      
>>>
>>I should add that problem functions could be coded something-like-this
>>to report errors.
>>
>>Version (Win95)
>>{
>>    CreateFileW(...)
>>    {
>>       static_assert("W Functions not supported in win95.");
>>    }
>>
>>)
>>else if (Hybrid)
>>{
>>   //Some solution that works for both win95 and winNT
>>}
>>else
>>{
>>   export CreateFileW(...); //Normal
>>
>>}
>>
>>Programmers wouldn't be able to use the function in a win95 product, but
>>at least they know it won't work.
>>
>>Anderson
>>    
>>
>
>I think you have the nexus of a good strategy here. The only challenge is
>not to have to build in a load of Win-specific stuff to the compiler or,
>heaven forfend, the language.
>
>Still, it's a puzzle that needs to be solved. Already there are new people
>who are complaining about writing Win32 code in D. I think that, even though
>it's Win32's problem not D's, D will still be deemed painful if it does not
>address these issues. We should remember that .NET handles all this filth,
>and Java obviates the discussion by disallowing interaction with the Win32
>(or any other) API. The bulk of people coming to D from that background will
>be peed off to be met with all these hidden nasties.
>
>
>  
>
I was thinking parhaps, something like the idea I present, could be used as an intermediate stage. Eventually when the problem is solved (this is in the general case, not just W functions), you would add the solution.

In article <btvshd$t8k$1@digitaldaemon.com>, Matthew says...

[...]

>I think you have the nexus of a good strategy here. The only challenge is not to have to build in a load of Win-specific stuff to the compiler or, heaven forfend, the language.
>
>Still, it's a puzzle that needs to be solved. Already there are new people who are complaining about writing Win32 code in D. I think that, even though it's Win32's problem not D's, D will still be deemed painful if it does not address these issues. We should remember that .NET handles all this filth, and Java obviates the discussion by disallowing interaction with the Win32 (or any other) API. The bulk of people coming to D from that background will be peed off to be met with all these hidden nasties.
>

If people want D to become a general-purpose and widely-used language, I think it is important to move away from any focus on a particular system. Adding win32 functionality into the language or compiler will lead to a niche language, much like Delphi. This I think would be a sad thing, D has a lot going for it.

Perhaps those of you who mainly write for Windows should consider how you would react if I started arguing for compiler and/or language support for Solaris specific features and Linux specific features.

I think these issues have to be addressed at the library level. I dont see any problem with having a layered set of D runtime libraries. After all, if you want to use STL in the Microsoft C++ compiler world, you have to rely on more than one runtime DLL from Microsoft, and this does not seem to prevent people accepting applications written this way. Not to mention the huge jar files for Java apps...

Ian

Ian Johnston wrote:

>In article <btvshd$t8k$1@digitaldaemon.com>, Matthew says...
>
>[...]
>
>  
>
>>I think you have the nexus of a good strategy here. The only challenge is
>>not to have to build in a load of Win-specific stuff to the compiler or,
>>heaven forfend, the language.
>>
>>Still, it's a puzzle that needs to be solved. Already there are new people
>>who are complaining about writing Win32 code in D. I think that, even though
>>it's Win32's problem not D's, D will still be deemed painful if it does not
>>address these issues. We should remember that .NET handles all this filth,
>>and Java obviates the discussion by disallowing interaction with the Win32
>>(or any other) API. The bulk of people coming to D from that background will
>>be peed off to be met with all these hidden nasties.
>>
>>    
>>
>
>If people want D to become a general-purpose and widely-used language, I think
>it is important to move away from any focus on a particular system. Adding
>win32 functionality into the language or compiler will lead to a niche language,
>much like Delphi. This I think would be a sad thing, D has a lot going for it.
>
>Perhaps those of you who mainly write for Windows should consider how you would
>react if I started arguing for compiler and/or language support for Solaris
>specific features and Linux specific features.
>
>I think these issues have to be addressed at the library level. I dont see any
>problem with having a layered set of D runtime libraries. After all, if you
>want to use STL in the Microsoft C++ compiler world, you have to rely on more
>than one runtime DLL from Microsoft, and this does not seem to prevent people
>accepting applications written this way. Not to mention the huge jar files for
>Java apps...
>
>Ian
>
>
>  
>
What about the SDL togglefullscreen mess?

That's why I suggest a hybrid mode. Most portable programs would be written in hybrid. In the beginning the hybrid mode would be highly restrictive, because lets face it, it's allot easier to port a single platform function to D then write a layer for it.  People who want to program to the metal still can. Using pragma's like I suggest, makes it easier to see which pieces of the code need to "fixed" for porting.  You'd be able to *almost* test other platforms (within the same OS -> to keep size down), without actually using them.  As the cross-platform layer grows, most people will have less use for win95, linux86 ect... pragmas.  But we need to use windows functions at the moment, and D only works for 2 platforms ATM anyway.

Anderson

> [...]
>
> >I think you have the nexus of a good strategy here. The only challenge is not to have to build in a load of Win-specific stuff to the compiler or, heaven forfend, the language.
> >
> >Still, it's a puzzle that needs to be solved. Already there are new
people
> >who are complaining about writing Win32 code in D. I think that, even
though
> >it's Win32's problem not D's, D will still be deemed painful if it does
not
> >address these issues. We should remember that .NET handles all this
filth,
> >and Java obviates the discussion by disallowing interaction with the
Win32
> >(or any other) API. The bulk of people coming to D from that background
will
> >be peed off to be met with all these hidden nasties.
> >
>
> If people want D to become a general-purpose and widely-used language, I
think
> it is important to move away from any focus on a particular system. Adding win32 functionality into the language or compiler will lead to a niche
language,
> much like Delphi.

This is all dependent on perspective. In so far as the discussion has implied, D already has Win32 functionality in the language, as it does Linux. I don't really grok what you mean, unless you object to Win32 (or Linux) -specific modules in the standard library.

> This I think would be a sad thing, D has a lot going for it.

There is the potential for this to be true, but it is by no means the certainty you imply.

> Perhaps those of you who mainly write for Windows should consider how you
would
> react if I started arguing for compiler and/or language support for
Solaris
> specific features and Linux specific features.

Frankly, this sounds to me like you're taking personal umbrage, at a perceived unwarranted focus on Win32.

I know little about Solaris, not having programmed at the GUI level on it. However, if:

1. Solaris, or any other Unixen, or indeed any other operating system, has
the same issues of an ostensibly compatible API with the various hidden
not-present or not-functioning functions / APIs that Win32 has, and
2. The success and/or failure of D in the short/medium term was
significantly linked to successful use on that/those platform(s)

then I would welcome it.

In fact, I'd welcome it anyway, because I'd be interested both generally and specifically in these issues.

It's irrelevant to me or to D that you don't want to discuss the need for D to succeed on Win32, or that you choose to see it as some slight on other operating systems. That in itself is strange.

Win32 has all these issues because Microsoft have consistently prioritised backwards compatibility. That has assured them, more than any other factor, of commercial success. Because of the commercial success, we need to take care that D is successful on this most visible of platforms. Because of the compatibility gotchas, that only come as a result of the backwards compatibility, that are there to provide the commercial success, that makes us care about D on Win32, we need to be concerned. It's not an ideal world, I didn't write the rules, it's a Catch 22, let's deal with it, eh?

> I think these issues have to be addressed at the library level. I dont see
any
> problem with having a layered set of D runtime libraries.

Isn't this what our discussion is trying to ascertain?

> After all, if you
> want to use STL in the Microsoft C++ compiler world, you have to rely on
more
> than one runtime DLL from Microsoft, and this does not seem to prevent
people
> accepting applications written this way.

This is not necessarily true. It's only so if people wish to communicate via STL objects between link-units, which is something that is often best reconsidered.

> Not to mention the huge jar files for
> Java apps...

Let's hear your suggestions ...

Matthew

Matthew wrote:

>>[...]
>>
>>    
>>
>>>I think you have the nexus of a good strategy here. The only challenge is
>>>not to have to build in a load of Win-specific stuff to the compiler or,
>>>heaven forfend, the language.
>>>
>>>Still, it's a puzzle that needs to be solved. Already there are new
>>>      
>>>
>people
>  
>
>>>who are complaining about writing Win32 code in D. I think that, even
>>>      
>>>
>though
>  
>
>>>it's Win32's problem not D's, D will still be deemed painful if it does
>>>      
>>>
>not
>  
>
>>>address these issues. We should remember that .NET handles all this
>>>      
>>>
>filth,
>  
>
>>>and Java obviates the discussion by disallowing interaction with the
>>>      
>>>
>Win32
>  
>
>>>(or any other) API. The bulk of people coming to D from that background
>>>      
>>>
>will
>  
>
>>>be peed off to be met with all these hidden nasties.
>>>
>>>      
>>>
>>If people want D to become a general-purpose and widely-used language, I
>>    
>>
>think
>  
>
>>it is important to move away from any focus on a particular system. Adding
>>win32 functionality into the language or compiler will lead to a niche
>>    
>>
>language,
>  
>
>>much like Delphi.
>>    
>>
>
>This is all dependent on perspective. In so far as the discussion has
>implied, D already has Win32 functionality in the language, as it does
>Linux. I don't really grok what you mean, unless you object to Win32 (or
>Linux) -specific modules in the standard library.
>
>  
>
>>This I think would be a sad thing, D has a lot going for it.
>>    
>>
>
>There is the potential for this to be true, but it is by no means the
>certainty you imply.
>
>  
>
>>Perhaps those of you who mainly write for Windows should consider how you
>>    
>>
>would
>  
>
>>react if I started arguing for compiler and/or language support for
>>    
>>
>Solaris
>  
>
>>specific features and Linux specific features.
>>    
>>
>
>Frankly, this sounds to me like you're taking personal umbrage, at a
>perceived unwarranted focus on Win32.
>
>I know little about Solaris, not having programmed at the GUI level on it.
>However, if:
>
>1. Solaris, or any other Unixen, or indeed any other operating system, has
>the same issues of an ostensibly compatible API with the various hidden
>not-present or not-functioning functions / APIs that Win32 has, and
>2. The success and/or failure of D in the short/medium term was
>significantly linked to successful use on that/those platform(s)
>
>then I would welcome it.
>
>In fact, I'd welcome it anyway, because I'd be interested both generally and
>specifically in these issues.
>
>It's irrelevant to me or to D that you don't want to discuss the need for D
>to succeed on Win32, or that you choose to see it as some slight on other
>operating systems. That in itself is strange.
>
>Win32 has all these issues because Microsoft have consistently prioritised
>backwards compatibility. That has assured them, more than any other factor,
>of commercial success. Because of the commercial success, we need to take
>care that D is successful on this most visible of platforms. Because of the
>compatibility gotchas, that only come as a result of the backwards
>compatibility, that are there to provide the commercial success, that makes
>us care about D on Win32, we need to be concerned. It's not an ideal world,
>I didn't write the rules, it's a Catch 22, let's deal with it, eh?
>
>  
>
>>I think these issues have to be addressed at the library level. I dont see
>>    
>>
>any
>  
>
>>problem with having a layered set of D runtime libraries.
>>    
>>
>
>Isn't this what our discussion is trying to ascertain?
>
>  
>
>>After all, if you
>>want to use STL in the Microsoft C++ compiler world, you have to rely on
>>    
>>
>more
>  
>
>>than one runtime DLL from Microsoft, and this does not seem to prevent
>>    
>>
>people
>  
>
>>accepting applications written this way.
>>    
>>
>
>This is not necessarily true. It's only so if people wish to communicate via
>STL objects between link-units, which is something that is often best
>reconsidered.
>
>  
>
>>Not to mention the huge jar files for
>>Java apps...
>>    
>>
>
>Let's hear your suggestions ...
>
>Matthew
>
>
>  
>
We'll said (as always!)

<snip>
>
> We'll said (as always!)

You're too kind.

I'm a simple man, in no need of praise. (And if you believe that ...)

In article <bu0jqf$257c$1@digitaldaemon.com>, Matthew says...
>
>> [...]
>>
>> >I think you have the nexus of a good strategy here. The only challenge is not to have to build in a load of Win-specific stuff to the compiler or, heaven forfend, the language.
>> >
>> >Still, it's a puzzle that needs to be solved. Already there are new
>people
>> >who are complaining about writing Win32 code in D. I think that, even
>though
>> >it's Win32's problem not D's, D will still be deemed painful if it does
>not
>> >address these issues. We should remember that .NET handles all this
>filth,
>> >and Java obviates the discussion by disallowing interaction with the
>Win32
>> >(or any other) API. The bulk of people coming to D from that background
>will
>> >be peed off to be met with all these hidden nasties.
>> >
>>
>> If people want D to become a general-purpose and widely-used language, I
>think
>> it is important to move away from any focus on a particular system. Adding win32 functionality into the language or compiler will lead to a niche
>language,
>> much like Delphi.
>
>This is all dependent on perspective. In so far as the discussion has implied, D already has Win32 functionality in the language, as it does Linux. I don't really grok what you mean, unless you object to Win32 (or Linux) -specific modules in the standard library.

No, I dont object at all to system-specific modules in the standard library, quite the opposite; I just thought I understood part of the discussion to be about adding system-specific features to the language. Maybe I just lost it somewhere :-)

>> This I think would be a sad thing, D has a lot going for it.
>
>There is the potential for this to be true, but it is by no means the certainty you imply.

Yes, indeed success on Windows platforms is very important, but it would be nice if it were not just Windows platforms, wouldn't it?

>> Perhaps those of you who mainly write for Windows should consider how you
>would
>> react if I started arguing for compiler and/or language support for
>Solaris
>> specific features and Linux specific features.
>
>Frankly, this sounds to me like you're taking personal umbrage, at a perceived unwarranted focus on Win32.

Sorry, I certainly didn't mean to come across that way, and even now I am not sure I understand how I created that impression :-))

I wasn't driving at that, I was just thinking, if you step back from any particular system's details, maybe it is easier to see that adding stuff to the language (see above) is limiting.

>I know little about Solaris, not having programmed at the GUI level on it. However, if:
>
>1. Solaris, or any other Unixen, or indeed any other operating system, has
>the same issues of an ostensibly compatible API with the various hidden
>not-present or not-functioning functions / APIs that Win32 has, and
>2. The success and/or failure of D in the short/medium term was
>significantly linked to successful use on that/those platform(s)
>
>then I would welcome it.

Not at the GUI level, but in other system calls, this can arise, particularly the difference between BSD-derivates and System V derivates.

On the GUI front, it is possibly an even bigger challenge, as there are various toolkits around these days, at least in the open source world.

>In fact, I'd welcome it anyway, because I'd be interested both generally and specifically in these issues.
>
>It's irrelevant to me or to D that you don't want to discuss the need for D to succeed on Win32, or that you choose to see it as some slight on other operating systems. That in itself is strange.

I do see a need to succeed on Win32. It would just be a pity if tons of D code had to be rewritten to succeed on Win64 or whatever.

>Win32 has all these issues because Microsoft have consistently prioritised backwards compatibility. That has assured them, more than any other factor, of commercial success. Because of the commercial success, we need to take care that D is successful on this most visible of platforms. Because of the compatibility gotchas, that only come as a result of the backwards compatibility, that are there to provide the commercial success, that makes us care about D on Win32, we need to be concerned. It's not an ideal world, I didn't write the rules, it's a Catch 22, let's deal with it, eh?

Yes, understood. Didn't think I was criticising that, is my English so bad? :-))

>> I think these issues have to be addressed at the library level. I dont see
>any
>> problem with having a layered set of D runtime libraries.
>
>Isn't this what our discussion is trying to ascertain?

Was it limited to libraries? Sorry, I thought there was a language element too.

>> After all, if you
>> want to use STL in the Microsoft C++ compiler world, you have to rely on
>more
>> than one runtime DLL from Microsoft, and this does not seem to prevent
>people
>> accepting applications written this way.
>
>This is not necessarily true. It's only so if people wish to communicate via STL objects between link-units, which is something that is often best reconsidered.
>
>> Not to mention the huge jar files for
>> Java apps...
>
>Let's hear your suggestions ...
>
>Matthew
>

Well, as implied, a core set of libraries with OS-independent functionality,
plus a layer for OS-specific-non-GUI functionality (get contents of a
directory, for example), then a GUI library. In the Windows case, there would
be different instances of modules for A/W etc items; I would expect these
however not to perform any runtime checks. If you tried to use a W library
where the OS does not support the functions, it won't load. This should be
a packaging issue, it seems to me.

I don't see this as anything new really; it is standard library packaging stuff.

Ian