xs0 wrote:
<snip>
> I think that the system is like this:
> 
> _WIN32_WINDOWS is defined only for Win95/98/Me (the crappy ones)
> _WIN32_WINNT is defined only for Win NT4/2k/XP/Vista/... (the OK ones)

When one writes a Windows application, it is often hoped that it will work on both lines of Windows.

> WINVER is defined for all Windows, and equals _WIN32_* for any given OS.
> 
> Now, the above condition does have to use an ||, as it's never the case that both are defined. It's also true that it could simply be (in this case)
<snip>

So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> xs0 wrote:
> <snip>
>> I think that the system is like this:
>>
>> _WIN32_WINDOWS is defined only for Win95/98/Me (the crappy ones)
>> _WIN32_WINNT is defined only for Win NT4/2k/XP/Vista/... (the OK ones)
> 
> When one writes a Windows application, it is often hoped that it will work on both lines of Windows.

You're absolutely right :)

>> WINVER is defined for all Windows, and equals _WIN32_* for any given OS.
>>
>> Now, the above condition does have to use an ||, as it's never the case that both are defined. It's also true that it could simply be (in this case)
> <snip>
> 
> So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set?

both
_WIN32_WINDOWS=0x0410
and
_WIN32_WINNT=0x0500

I was obviosuly wrong in saying that both are never defined :) I should get more sleep before posting next time. It should still be ||, though, because otherwise you'd always have to declare both, and there's no real need.

BTW, wouldn't something like this work for CC:

version(WINAPI_98) {
    version=WINAPI_95;
}

version(WINAPI_ME) {
    version=WINAPI_98;
    version=WINAPI_95;
}

version(WINAPI_95) {
    // win 95 funcs
}

version(WINAPI_98) {
    // funcs new in Win 98
}

version(WINAPI_ME) {
    // funcs new in Win Me
}


Then, when compiling, you can set the api version you want with -version=?. If you don't set it, it should probably default to the latest known version?


xs0

Stewart Gordon wrote:
> Don Clugston wrote:
>> Stewart Gordon wrote:
> <snip>
>>> Now, who's going to contribute?
>>
>> I hope that I can do a bit.
> 
> Excellent!
> 
> <snip>
>>> Defining a set of version identifiers for the supported Windows versions along the Win9x and WinNT lines is another possibility, but it'll take a bit of work to determine how the #ifs should be converted.
>>
>> It's possible to use 'static if', now that it works at module scope.
>>
>> #if (WINVER > 0x4000)
>> #else
>> #endif
>> can become
>> static if (WINVER> 0x4000) {
>> } else {
>> }
>>
>> It's probably abuse of 'static if', but it should work as an interim solution.
> 
> Where would the user set WINVER?  A module for the user to edit to supply this data might be one possibility, but it would be a nightmare for someone maintaining or even trying to compile several projects that have different OS requirements.  But for as long as it's only an interim solution....
> It would also be nice if the policy for using the versions is clearer than the WINVER/_WIN32_WINDOWS/_WIN32_WINNT stuff is at the moment.  At the moment, I'm puzzled by the number of instances of this
> 
> #if (_WIN32_WINDOWS >= 0x0410 || _WIN32_WINNT >= 0x0500)
> 
> or similar.  It seems to be saying that the function may be used by either an application that supports Win98 or an application that supports Win2000.  So you could have a program that works on Windows 98 and Windows NT4 but not Windows 95, or a program that works on Windows 95 and Windows 2000 but not Windows NT4, and whatever is in that #if would be available to either.  Unless I'm misunderstanding, it would appear that the || should be an &&.

To quote windef.h:
----------------------
#ifndef WINVER
#define WINVER 0x0400
/*
 * If you need Win32 API features newer the Win95 and WinNT then you must
 * define WINVER before including windows.h or any other method of including
 * the windef.h header.
 */
#endif
#ifndef _WIN32_WINNT
#define _WIN32_WINNT WINVER
/*
 * There may be the need to define _WIN32_WINNT to a value different from
 * the value of WINVER.  I don't have any example of why you would do that.
 * However, if you must then define _WIN32_WINNT to the value required before
 * including windows.h or any other method of including the windef.h header.
 */
#endif
----------------
My conclusion -- Seems stupid to me, I bet this is historical. Since D doesn't need to support 1990's legacy D code, we should be able to clean it up.

xs0 wrote:
> Stewart Gordon wrote:
>> xs0 wrote:
<snip>
>>> Now, the above condition does have to use an ||, as it's never the case that both are defined. It's also true that it could simply be (in this case)
>> <snip>
>>
>> So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set?
> 
> both
> _WIN32_WINDOWS=0x0410
> and
> _WIN32_WINNT=0x0500

And leave WINVER undefined?

> I was obviosuly wrong in saying that both are never defined :) I should get more sleep before posting next time. It should still be ||, though, because otherwise you'd always have to declare both, and there's no real need.

I think I see what you mean now.

> BTW, wouldn't something like this work for CC:
> 
> version(WINAPI_98) {
>     version=WINAPI_95;
> }

I was thinking something like this myself.  Though with names like Windows98, WindowsME, Windows2000 rather than WINAPI_*.

<snip>
> Then, when compiling, you can set the api version you want with -version=?. If you don't set it, it should probably default to the latest known version?

This structure would imply that not setting it would default to the earliest known version.  As is the case with the C headers.  I was thinking of 95/NT4 being the default level and versioning to enable higher Windows versions.

I'll study the headers a bit more and correlate them with the info on the MSDN site.  This should help to understand what should be enabled when.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

I'll help out on this project, too.  I've got some of the smaller bits done, but an official answer to how to handle this consistently will be necessary before I can do too much more.

Here's some of the stuff I think is done and works, but I haven't had a chance to really do anything do test it yet.

http://www.summerseas.com/jpelcis/downloads/win32-032906.zip

Stewart Gordon wrote:
> xs0 wrote:
>> Stewart Gordon wrote:
>>> xs0 wrote:
> <snip>
>>>> Now, the above condition does have to use an ||, as it's never the case that both are defined. It's also true that it could simply be (in this case)
>>> <snip>
>>>
>>> So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set?
>>
>> both
>> _WIN32_WINDOWS=0x0410
>> and
>> _WIN32_WINNT=0x0500
> 
> And leave WINVER undefined?
> 
>> I was obviosuly wrong in saying that both are never defined :) I should get more sleep before posting next time. It should still be ||, though, because otherwise you'd always have to declare both, and there's no real need.
> 
> I think I see what you mean now.
> 
>> BTW, wouldn't something like this work for CC:
>>
>> version(WINAPI_98) {
>>     version=WINAPI_95;
>> }
> 
> I was thinking something like this myself.  Though with names like Windows98, WindowsME, Windows2000 rather than WINAPI_*.
> 
> <snip>
>> Then, when compiling, you can set the api version you want with -version=?. If you don't set it, it should probably default to the latest known version?
> 
> This structure would imply that not setting it would default to the earliest known version.  As is the case with the C headers.  I was thinking of 95/NT4 being the default level and versioning to enable higher Windows versions.
> 
> I'll study the headers a bit more and correlate them with the info on the MSDN site.  This should help to understand what should be enabled when.
> 
> Stewart.
> 

James Pelcis wrote:
> I'll help out on this project, too.  I've got some of the smaller bits done, but an official answer to how to handle this consistently will be necessary before I can do too much more.
> 
> Here's some of the stuff I think is done and works, but I haven't had a chance to really do anything do test it yet.
> 
> http://www.summerseas.com/jpelcis/downloads/win32-032906.zip
<snip top of upside-down reply>

Thanks.  But please use the Wiki4D page to assign files to yourself. That's what it's there for - so we can avoid duplication of effort.  And you appear to have so far only done the basic translation and not had a good look through the instructions.

And looking at dxerr8/9 in particular:
- It's version (Unicode) not version (UNICODE).

- We ought to define a debug identifier rather than using debug by itself.  Since this is the only place where DEBUG is used, maybe debug (dxerr) or something similar?

- You've separated the debug macros into ANSI and Unicode versions. Totally unnecessary.  All A/W specific types have versioned aliases. This includes char/wchar, for which the alias is TCHAR.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Hi Stewart,
Here's a translation of wingdi, one of the largest headers.
It doesn't yet _fully_ comply with your requirements (although I think
it's not too bad), but I'm loathe to modify it further without better
testing. It was a lot of work already to get it to that stage. I think
we need to get some of the early headers in Windows.h done, so that the
later ones can compile.

-Don.

Stewart Gordon wrote:
> Don Clugston wrote:
>> Stewart Gordon wrote:
> <snip>
>>> Now, who's going to contribute?
>>
>> I hope that I can do a bit.
> 
> Excellent!
> 
> <snip>
>>> Defining a set of version identifiers for the supported Windows versions along the Win9x and WinNT lines is another possibility, but it'll take a bit of work to determine how the #ifs should be converted.
>>
>> It's possible to use 'static if', now that it works at module scope.
>>
>> #if (WINVER > 0x4000)
>> #else
>> #endif
>> can become
>> static if (WINVER> 0x4000) {
>> } else {
>> }
>>
>> It's probably abuse of 'static if', but it should work as an interim solution.
> 
> Where would the user set WINVER?  A module for the user to edit to supply this data might be one possibility, but it would be a nightmare for someone maintaining or even trying to compile several projects that have different OS requirements.  But for as long as it's only an interim solution....
> 
> It would also be nice if the policy for using the versions is clearer than the WINVER/_WIN32_WINDOWS/_WIN32_WINNT stuff is at the moment.  At the moment, I'm puzzled by the number of instances of this
> 
> #if (_WIN32_WINDOWS >= 0x0410 || _WIN32_WINNT >= 0x0500)
> 
> or similar.  It seems to be saying that the function may be used by either an application that supports Win98 or an application that supports Win2000.  So you could have a program that works on Windows 98 and Windows NT4 but not Windows 95, or a program that works on Windows 95 and Windows 2000 but not Windows NT4, and whatever is in that #if would be available to either.  Unless I'm misunderstanding, it would appear that the || should be an &&.
> 
> Stewart.
> 

Kyle Furlong wrote:
> J C Calvarese wrote:
>> What's freer than releasing it as public domain? Public domain would be my
>> preference if it were my choice.
>>
>> jcc7
> 
> 
> The problem with releasing anything into the public domain is that eventually it becomes ambiguous that it IS public domain. People drop the work anywhere and however they please, and somewhere down the line someone asks, "Hey what is the licensing of such and such." If the project is inactive its easy for this ambiguity to arise. Thus, having an explicit license which stipulates that use of the work is completely free, and that copies of the license must be distributed with the work avoid this.

And, releasing in the public domain seems to be problematic in itself, at least in some countries. In the Ares 0.15 release thread I wrote:

It appears you cannot simply donate files to the public domain.
According to Lawrence Rosen [1], an attorney who served for many years
as general counsel and secretary of the Open Source Initiative, "there
is no accepted way to dedicate an original work of authorship to the
public domain before the copyright term for that work expires. A license
is the only recognized way to authorize others to undertake the authors’
exclusive copyright rights." This is the raison d'être of all-permissive
licenses like MIT, BSD etc.

[1] Lawrence Rosen, 2004, "Open Source Licensing -- Software Freedom and
Intellectual Property Law", Prentice Hall, New Yersey, page 74,
http://www.rosenlaw.com/Rosen_Ch05.pdf

Don Clugston wrote:
> Hi Stewart,
> Here's a translation of wingdi, one of the largest headers.
> It doesn't yet _fully_ comply with your requirements (although I think it's not too bad), but I'm loathe to modify it further without better testing. It was a lot of work already to get it to that stage. I think we need to get some of the early headers in Windows.h done, so that the later ones can compile.
<snip>

I've just had a look.  I hadn't really thought about testing the translation, with there being so much to test and bits of the API to get to grips with in doing so.

I see you've begun to implement your "interim solution" on the Windows versions....

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Don Clugston wrote:
>> Hi Stewart,
>> Here's a translation of wingdi, one of the largest headers.
>> It doesn't yet _fully_ comply with your requirements (although I think it's not too bad), but I'm loathe to modify it further without better testing. It was a lot of work already to get it to that stage. I think we need to get some of the early headers in Windows.h done, so that the later ones can compile.
> <snip>
> 
> I've just had a look.  I hadn't really thought about testing the translation, with there being so much to test and bits of the API to get to grips with in doing so.

What would be great would be a 'force extern' dmd option for linking: ensure that every extern function actually exists in the import library.
Right now you can write:
extern (Windows) { void SomeOldGarbage(); }
and it will compile without error. If we had such a feature, we could at least check that all functions were defined correctly.

One way of doing it would be take one of those Dparser projects and just create a main() function which creates function pointers to every function mentioned in the file. But obviously it would be better if Walter could create an option to do the same thing. It would help all conversion from C->D.

> I see you've begun to implement your "interim solution" on the Windows versions....

I didn't use the Perl script, I used my half-baked C2D converter to do the initial conversion. It's a moderately correct preprocessor with an regex replacement of the simple D types. #ifdef to static if is something it does semi-automatically.

I still don't know what's the right way to do it. Function definitions are OK, but those structs that have additional members...