January 23, 2012
On Sunday, January 22, 2012 13:02:12 Walter Bright wrote:
> I think we ought to support things as long as MS officially does. After that, I'm game at abandoning official support, if for no other reason than not being able to develop/debug/test on those platforms.

Then can we just agree to drop support for pre-Win2K Windows platforms? Being able to remove all of the stuff like `useWfuncs` would definitely allow us to clean up the Windows-related code in Phobos. Having to worry about it has definitely increased the complexity of the Windows API code in Phobos.

- Jonathan M Davis
January 23, 2012
On 1/22/2012 7:47 PM, Jonathan M Davis wrote:
> Being able to remove all of the stuff like `useWfuncs` would definitely allow us to
> clean up the Windows-related code in Phobos. Having to worry about it has
> definitely increased the complexity of the Windows API code in Phobos.

I wrote much of that code, and it did not make the code terribly dirty or gross or excessively complex. It's a minor detail. The main issue, as far as I'm concerned, is the existing code never gets tested on Win95 anymore, so we don't know if it works.
January 23, 2012
I find it kind of funny that someone would use a *new* language to support an *ancient* platform. If someone is still hacking with win9x support I bet their dev environment is -- VC6.
January 23, 2012
On Sunday, January 22, 2012 19:55:21 Walter Bright wrote:
> On 1/22/2012 7:47 PM, Jonathan M Davis wrote:
> > Being able to remove all of the stuff like `useWfuncs` would definitely allow us to clean up the Windows-related code in Phobos. Having to worry about it has definitely increased the complexity of the Windows API code in Phobos.
> I wrote much of that code, and it did not make the code terribly dirty or gross or excessively complex. It's a minor detail. The main issue, as far as I'm concerned, is the existing code never gets tested on Win95 anymore, so we don't know if it works.

It's not horrible, but it does complicate the code. I know that it's caused some issues for the folks adding to std.windows.registry. And it has to be maintained as other changes are made. For instance, I'd like to go in and make std.file support string types of wchar and dchar. But toMBSz doesn't support anything other than strings of char, so I'm going to have to go and make toMBSz support other string types, and all for platforms that are more or less dead. If we got rid of useWfuncs, then that's not a problem anymore, but we can't do that as long as we try and support pre-Win2K.

- Jonathan M Davis
January 23, 2012
On 1/22/2012 8:04 PM, Jonathan M Davis wrote:
> It's not horrible, but it does complicate the code. I know that it's caused
> some issues for the folks adding to std.windows.registry. And it has to be
> maintained as other changes are made. For instance, I'd like to go in and make
> std.file support string types of wchar and dchar. But toMBSz doesn't support
> anything other than strings of char, so I'm going to have to go and make
> toMBSz support other string types, and all for platforms that are more or less
> dead. If we got rid of useWfuncs, then that's not a problem anymore, but we
> can't do that as long as we try and support pre-Win2K.

Why make std.file support wchar and dchar? You triple the number of functions, all for rarely used cases, and one where the user can trivially convert wstring to string at the call site.

January 23, 2012
On Sunday, January 22, 2012 20:58:33 Walter Bright wrote:
> Why make std.file support wchar and dchar? You triple the number of functions, all for rarely used cases, and one where the user can trivially convert wstring to string at the call site.

It doesn't triple the number of functions. You just templatize them. You only get triple the number of functions if you actually use them with all 3 string types. But we've had complaints in general about Phobos functions only supporting string rather than char[] or wstring or whatever. Templatizing std.file's functions on string types helps alleviate that. And on Windows, it would even allow you to pass a wstring without having to convert to a string first and then back to a wstring to pass to the Windows API functions, which could reduce that number of string operations required for file operations. Regardless, the idea is to make the functions more flexible. They don't _need_ to be restricted to string specifically.

- Jonathan M Davis
January 23, 2012
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.716.1327278278.16222.digitalmars-d@puremagic.com...
> On Monday, January 23, 2012 00:14:27 Stewart Gordon wrote:
>> On 22/01/2012 23:48, Jonathan M Davis wrote:
>> <snip>
>>
>> > It would be insane to not support XP at this point. Not only does XP still support it, but there are tons of people who have refused to move on. IIRC, Microsoft was effectively forced to support it longer because of the number of people (particularly companies) who refused to upgrade. However, I see no reason to support anything older than XP.
>>
>> <snip>
>>
>> Principle of least surprise.  Somebody compiling for a given target
>> platform
>> should expect whether it runs on a given version of the platform to be
>> down
>> to the APIs the program uses, not the language the program is written in.
>
> Except that druntime and Phobos use those APIs. So, it matters. And since
> the
> number of people using pre-Win2K is extremely low, I see that as a
> complete
> non-issue.
>
>> Moreover, it seems a lot of currently maintained software still claims to support Win2000 - Firefox and OpenOffice for instance.  For a whole programming language, the majority of whose users will be writing much simpler programs than this, to have higher system requirements than this seems absurd.
>
> As I said in my previous post, while ideally we'd say that we don't
> support
> anything older than WinXP, saying that we support Win2K probably costs us
> nothing. It's the pre-Win2K that's the problem with the lack of W
> functions
> and the like.
>
> The next version of Windows beyond that that it would be useful to be able
> to
> say that we don't support anything older than is Vista. I would _love_ to
> be
> able to do that Vista is the oldest that we support, because Vista added a
> bunch of useful API calls and the like. But we obviously can't do that
> anytime
> soon. The user base for XP is huge. The same can't be said of pre-Win2K.
>
> So, I really think that we should say that we don't support pre-Win2K, and
> I'd
> like to say that we don't support pre-XP, but I don't think that it hurts
> us
> any to say that we support Win2K.
>

I agree on all points.

But you know, the really bizarre thing is, *all* MS has to do to win over all the XP people (or at least the majority of them) is two simple things:

1. *Allow* people to use the XP UI (and no, I don't mean Luna). It's that simple: Just *quit* making UI changes mandatory (a lesson Mozilla could stand to learn, too, especially since they allegedly care so much about configurability).

2. Ditch the AV-crippling and driver-revocation bullshit.

That's it. That's all they have to do. The core of Win7 is basically solid (from what I hear). But they can't handle that, can they? Talk about digging one's own grave. Heck, I wouldn't be surprised if Vista and Win7 (and Win8) have not only caused people to stick with XP, but also caused a lot of Win->Lin converts - I'm getting closer and closer to that myself. All they (or Mozilla) seem to care about anymore is just fucking around with the UI everyone already liked - and redoing it over, and over, and over.


January 23, 2012
On Monday, 23 January 2012 at 05:30:48 UTC, Nick Sabalausky wrote:
> 1. *Allow* people to use the XP UI (and no, I don't mean Luna).

You can...

> Heck, I wouldn't be surprised if Vista and Win7 (and Win8) have not only caused people to stick with XP, but also caused a lot of Win->Lin converts

I'd be very surprised if it did.
January 23, 2012
"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.722.1327291162.16222.digitalmars-d@puremagic.com...
>I find it kind of funny that someone would use a *new* language to
> support an *ancient* platform. If someone is still hacking with win9x support I bet their dev environment is -- VC6.

While I agree 9x isn't worth supporting, calling it "ancient" is pure hyperbole. CP/M is ancient. ProDOS is arguably ancient. Hell, Win2 could even be called ancient. Win9x is just simply old/outdated. Christ, it includes an OS (WinMe) that's arguably *ONE* version prior to a version that's still heavily used - XP. (Hell, even Win98 was the version that *most* people used immediately prior to the still-heavily-used XP).

I know I'm going all off on something that really is nitpicky, but misuse of grandiose words like "ancient", "epic", etc., to refer to fairly trivial matters is a bit of a pet peeve...

(Hell, using "ancient" to refer to "computers more than 5-10 years old" is itself rather..."ancient".)


January 23, 2012
"Nick Sabalausky" <a@a.a> wrote in message news:jfis68$2uv7$1@digitalmars.com...
> "Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.722.1327291162.16222.digitalmars-d@puremagic.com...
>>I find it kind of funny that someone would use a *new* language to
>> support an *ancient* platform. If someone is still hacking with win9x support I bet their dev environment is -- VC6.
>
> While I agree 9x isn't worth supporting, calling it "ancient" is pure hyperbole. CP/M is ancient. ProDOS is arguably ancient. Hell, Win2 could even be called ancient. Win9x is just simply old/outdated. Christ, it includes an OS (WinMe) that's arguably *ONE* version prior to a version that's still heavily used - XP. (Hell, even Win98 was the version that *most* people used immediately prior to the still-heavily-used XP).
>
> I know I'm going all off on something that really is nitpicky, but misuse of grandiose words like "ancient", "epic", etc., to refer to fairly trivial matters is a bit of a pet peeve...
>
> (Hell, using "ancient" to refer to "computers more than 5-10 years old" is itself rather..."ancient".)
>

FWIW, I do agree that "new language on an...outdated...platform" does have an air of anachronism.