Add Windows 2000 support #212

Closed
wants to merge 2 commits into
from

Projects

None yet

6 participants

@denis-sh
  • Windows 2000 doesn't have RtlCaptureContext

RtlCaptureContext from core.sys.windows.stacktrace makes every D progrum unlaunchable on Windows 2000 for a long time (see Issue 6024).

TODO: There is no TzSpecificLocalTimeToSystemTime in Windows 2000 too. Something with it must be done in this pull.

@denis-sh

@jmdavis, is there any easy way to not use TzSpecificLocalTimeToSystemTime in std.datetime on Win2k? If there is no easy workaround, I'll just add throwing dummy to this pull.

@jmdavis
D Programming Language member

No, there is no easy way not to use it. If you do much of anything with SysTime on Windows, it's going to get called. Depending on what Win2K does, it might be possible to implement it, but that's not exactly fun. But that's really bizarre that SystemTimeToTzSpecificLocalTime is available on Win2K, but TzSpecificLocalTimeToSystemTime isn't. That's one more reason why it would be nice to just say that you need XP or newer.

@denis-sh

By the way, SysTime.fromISOExtString (from the first docs example) fails on Win2k with assert(0) or HLT instruction so lack of TzSpecificLocalTimeToSystemTime isn't a biggest problem (I haven't managed to call it from std.datetime API in five minutes).

Since std.datetime is the only module affected by Win2k I vote for restoring its partial support and marking std.datetime as "Unstable on Windows 2000 because of lack of system API in this OS".

P.S.
I'm not a fan of Win2k, but it just wasn't pleasant when its support was silently broken.

@jmdavis
D Programming Language member

Any function call on SysTime which requires converting it to its time zone rather than leaving it in UTC (which includes all of the property functions for parts of the date/time - year, hour, minute, etc. - as well as the various toXString functions, among others) will fail on Windows without TzSpecificLocalTimeToSystemTime. If you haven't been able to get it to blow up much, you haven't try very many of SysTime's functions. _dstInEffect requires TzSpecificLocalTimeToSystemTime, and _utcToTZ requires _dstInEffect, and LocalTime's and WindowsTimeZone's utcToTZ require _utcToTZ, and utcToTZ is used in SysTime's adjTime, which is called all over the place in SysTime.

If we want to mark std.datetime as not working properly on Win2K, that's fine, since it doesn't, but it's worse than unstable. SysTime is useless on Win2K if you ever want any kind of presentation time or ever care about how a time correlates to any time zone other than UTC.

@denis-sh

Another 5 minutes, no TzSpecificLocalTimeToSystemTime hit. Only other Win2K failures. My example:

import std.stdio;
import std.datetime;
void main()
{
    writeln(WindowsTimeZone.getInstalledTZNames());
    // n = 0, 2 - passes
    // n = 1, 3 - fails in tzToUTC with `assert(0) or HLT instruction`
    enum n = 1;
    auto tz = WindowsTimeZone.getTimeZone(WindowsTimeZone.getInstalledTZNames()[n]);
    auto k = tz.utcToTZ(123);
    writeln("TZ: ", k);
    writeln("UTC: ", tz.tzToUTC(k));
    readln();
}

I just want to say that even if some hero will implement TzSpecificLocalTimeToSystemTime by hands it will not help at all.

And thanks for your quick replies!

@denis-sh

Damn, I've got it just now. TzSpecificLocalTimeToSystemTime call is wrapped in try .. catch assert(0) and HLT instruction is the result of thrown exception.

May I ask why?

@jmdavis
D Programming Language member

The function the call is in is nothrow, so it can't throw, and nothing inside of that try-catch block should ever throw.

Oh, and it looks like you're not seeing as many failures as I thought that you should, because I was looking at the wrong function (SystemTimeToTzSpecificLocalTime instead of TzSpecificLocalTimeToSystemTime), but stuff is still going to fail if either of those functions is not available. And there are assertions which will fail if either of those functions fail, because they should never fail (though most of them aren't assert(0)). Those functions are required. If they're missing, you can't expect anything using them not to blow up.

@MartinNowak MartinNowak commented on the diff May 21, 2012
src/core/sys/windows/stacktrace.d
@@ -27,12 +27,61 @@ import core.stdc.stdio;
extern(Windows)
{
DWORD GetEnvironmentVariableA(LPCSTR lpName, LPSTR pBuffer, DWORD nSize);
- void RtlCaptureContext(CONTEXT* ContextRecord);
+ version(Win32) // For Windows 2000 support
+ {
+ alias void function(CONTEXT* ContextRecord) RtlCaptureContextFunc;
+
+ void m_RtlCaptureContext(CONTEXT* ContextRecord)
@MartinNowak
MartinNowak May 21, 2012

How about adding version(D_InlineAsm_X86) in front of the function?

@denis-sh

By the way, TLS fixing algorithm (core.sys.windows.dll.addTlsListEntry) should fail on Windows 2000.

@denis-sh

So what we will do with Windows 2000? Personally I don't like this pull request. It makes not-very-good-looking druntime uglier. I'd like voting about this to be done. Something like:

  1. Officially announce that minimum supported Windows version is 5.1 (aka XP) since v2.053
    1. Add link like "Email @denis-sh to get D stuff with partial support for Windows 2000".
    2. Just call all Windows 2000 users dinosaurs.
  2. [A bit improve and] Merge this pull and officially announce that Windows 2000 is partially supported.
  3. Maniacally add full Windows 2000 support.
  4. Leave Issue 6024 opened forever.
@denis-sh

Oh, it's few days more than a year Windows 2000 is silently unsupported!

@andralex
D Programming Language member

So should I just close this? @denis-sh sorry for neglecting your work... but probably we should go with the times and repudiate Windows 2000.

@jmdavis
D Programming Language member

I say close it.

@LightBender

I would go with closing this AND Issue 6024
Windows 2000 is no longer supported by MS and is only a minute fraction of the windows install base.

@alexrp
D Programming Language member

I vote for just killing Windows 2000 support.

@jmdavis
D Programming Language member

Certainly, taking the approach of saying that we only support versions of Windows that Microsoft still supports simplifies things. I'll close this then. There hasn't exactly been huge support behind keeping Win2k support when it's been discussed in the newsgroup either.

@jmdavis jmdavis closed this Jul 8, 2012
@denis-sh

Excellent! We finally agree to stop Win2k support.
But Issue 6024 require us to note this in changelog/download pages to be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment