It came up as an aside in the earlier discussion about moving to uintmax_t, but I was wondering - is there any interest in a port to windows? I've got most of the way to a successful zic port (other tools don't work so well yet - everything compiles, but there are subtle incompatibilities that cause problems for the library functions) -- Random832
On 03/08/13 11:29, random832@fastmail.us wrote:
is there any interest in a port to windows?
If it can be mostly partitioned into a separate area, which normally doesn't affect the mainline version, there'd be some interest I suppose. I hope it wouldn't require many intrusive changes to the existing source.
On Fri, Mar 8, 2013, at 14:39, Paul Eggert wrote:
If it can be mostly partitioned into a separate area, which normally doesn't affect the mainline version, there'd be some interest I suppose. I hope it wouldn't require many intrusive changes to the existing source.
The only substantial source changes I had to make to make zic work were: Include a version of getopt (need one that's public-domain - I just used a BSD one I found online for testing - anyone know where a PD one can be found?) or (less appealing) implement command-line parsing manually. Implemented windows versions of link and symlink. (Separate file). Ideally, a file-copying solution needs to be implemented, and it bails out if the link function returns an error (i.e. file already exists). And of course a windows-specific makefile. I'm less confident about the library functions. Part of the problem is that to make them useful they need to not only work but be able to replace the MSVC library functions when building a program. It might be worthwhile, in general, to have a _separate_ library for converting times using tzdata zones, that doesn't attempt to replace the system tzset/localtime/etc functions. I bet that fails your "intrusive changes to the existing source" test, though. The biggest problem I ran into with date is that it requires _some_ way to set the system clock, so I need to implement a windows function to do so, or figure out a way to block out all time-setting functionality at build time - I've also had problems getting it to "see" MSVC's library functions - some header that's not being included or something, haven't had time to track it down yet. Haven't looked at zdump yet, and it's less useful without the library functions anyway. I also implemented a C version of yearistype, and a tzfile inspector tool - the latter is something I've always wondered about the absence of from the main distribution... zdump's output has a more abstract relationship to the contents of zone files, this is meant to replace byte-by-byte inspection in a hex editor - its parsing code is also mostly independent of the library's. Those are more or less independent of the rest, I can send them later this weekend [still have some bugs in the inspector] -- Random832
On Fri, Mar 8, 2013 at 12:42 PM, <random832@fastmail.us> wrote:
On Fri, Mar 8, 2013, at 14:39, Paul Eggert wrote:
If it can be mostly partitioned into a separate area, which normally doesn't affect the mainline version, there'd be some interest I suppose. I hope it wouldn't require many intrusive changes to the existing source.
The only substantial source changes I had to make to make zic work were: Include a version of getopt (need one that's public-domain - I just used a BSD one I found online for testing - anyone know where a PD one can be found?)
I have a copy of the getopt() that AT&T released into the public domain way back in the 80s. The original is in pre-standard C (not prototyped) but I looked it out recently: The preamble starts: /* ** @(#)getopt.c 2.2 (smail) 1/26/87 */ #ifndef lint static char sccs[] = "@(#)Public Domain: $RCSfile: getopt.c,v $ $Revision: 1.1 $"; #endif /* * Here's something you've all been waiting for: the AT&T public domain * source for getopt(3). It is the code which was given out at the 1985 * UNIFORUM conference in Dallas. I obtained it by electronic mail * directly from AT&T. The people there assure me that it is indeed * in the public domain. * * There is no manual page. That is because the one they gave out at * UNIFORUM was slightly different from the current System V Release 2 * manual page. The difference apparently involved a note about the * famous rules 5 and 6, recommending using white space between an option * and its first argument, and not grouping options that have arguments. * Getopt itself is currently lenient about both of these things White * space is allowed, but not mandatory, and the last option in a group can * have an argument. That particular version of the man page evidently * has no official existence, and my source at AT&T did not send a copy. * The current SVR2 man page reflects the actual behavor of this getopt. * However, I am not about to post a copy of anything licensed by AT&T. */ If I remember correctly, I collected the code from the 'smail' mail agent — the first check-in in my RCS (originally SCCS) respository was in April 1988. I don't think I have the source for smail any more. (The smail 3 source is available via its home page at http://www.weird.com/~woods/projects/smail.html; the last release was in 2005. It contains substantially the notice above and the original source code, so you don't have to rely on me.) The process of bringing the code up to date is straight-forward as long as you don't want to support the POSIX-mandated ( http://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html) 'optional argument' processing, which is actually fairly useless anyway (I'll bore you with the details on request — suffice to say only the last option argument can be optional). -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0118 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On Fri, Mar 8, 2013 at 11:29 AM, <random832@fastmail.us> wrote:
It came up as an aside in the earlier discussion about moving to uintmax_t, but I was wondering - is there any interest in a port to windows? I've got most of the way to a successful zic port (other tools don't work so well yet - everything compiles, but there are subtle incompatibilities that cause problems for the library functions)
I mentioned it. It isn't any sort of priority item to me, personally. However, at work, I have to pay passing attention to Windows and have hopes to get time zone information from data produced by zic into a product, but as long as zic works on Unix and the files can be transported to Windows, that's (probably) fine — though having zic compile on Windows would simplify customer-upgrades using the latest version of the TZ data. All very much in the future. (And yes, I'm sure there are APIs on Windows for the job; they're different from the Unix ones and that presents a problem. And the uniform data source will be important, so people who use our product on Windows and Unix will be able to get the same time-zone results on both platforms, independently of whether the o/s is upgraded. I believe it would allow them more timely access to the changes that occur.) -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0118 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On 2013-03-08 12:56, Jonathan Leffler wrote:
On Fri, Mar 8, 2013 at 11:29 AM, <random832@fastmail.us <mailto:random832@fastmail.us>> wrote:
It came up as an aside in the earlier discussion about moving to uintmax_t, but I was wondering - is there any interest in a port to windows? I've got most of the way to a successful zic port (other tools don't work so well yet - everything compiles, but there are subtle incompatibilities that cause problems for the library functions)
I mentioned it. It isn't any sort of priority item to me, personally. However, at work, I have to pay passing attention to Windows and have hopes to get time zone information from data produced by zic into a product, but as long as zic works on Unix and the files can be transported to Windows, that's (probably) fine — though having zic compile on Windows would simplify customer-upgrades using the latest version of the TZ data. All very much in the future. (And yes, I'm sure there are APIs on Windows for the job; they're different from the Unix ones and that presents a problem. And the uniform data source will be important, so people who use our product on Windows and Unix will be able to get the same time-zone results on both platforms, independently of whether the o/s is upgraded. I believe it would allow them more timely access to the changes that occur.)
tzcode is supported under Windows by djgpp (2.03 for DOS and 2.04 for Windows 32 bit only), MinGW, and cygwin.
I've been meaning to ask this and kept having other things to do, and wanted to wait for the australia stuff to be resolved before starting what could be another large discussion (my patch has been sitting mostly completed for weeks) On Sat, Mar 9, 2013, at 1:51, Brian Inglis wrote:
tzcode is supported under Windows by djgpp (2.03 for DOS and 2.04 for Windows 32 bit only), MinGW, and cygwin.
Can you provide details of this support? I don't want to break anything. As I understand it, cygwin has its own fork of tzcode (and I dislike how it handles system timezones when TZ is unset), rather than providing any meaningful support for tzcode itself. And I'm not sure what the extent of being able to "support" it with mingw is - compile zic and zdump? easy. (though there are issues with hardlinks and the "itsdir" function in zic that I doubt mingw properly fixes) compile the library functions so you can link any program against it and have it magically work? likely not so much. I'd like to try building it with at least mingw myself, are there any special steps required?
---------------8<------------------------------------- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of random832@fastmail.us Sent: 08 March 2013 19:30 To: tz@iana.org Subject: [tz] tzcode for windows? [Scanned] It came up as an aside in the earlier discussion about moving to uintmax_t, but I was wondering - is there any interest in a port to windows? I've got most of the way to a successful zic port (other tools don't work so well yet - everything compiles, but there are subtle incompatibilities that cause problems for the library functions) -- Random832 ---------------8<------------------------------------- I use the tz data under Windows: I use a heavily-modified (and compiled as C++) version of zic, which generates a single file, basically a Zip archive, containing all the compiled tz data and aliases (including extra ones for the Windows idea of timezones). This file is then loaded by a C++ library which contains a heavily-modified form of the tz formatting code to allow multiple timezones to be used within a single application. In day-to-day use I'm not attempting to use the tz code to in place of the C library routines, so am not reliant on always being able to compile and use the latest tz code. However, it is very useful to be able to compile and run it, in order to double-check my zic-alike and formatting routines - and, as they originated with tz code some years ago, copy across the odd code fix. So, I'm always interested in whether zic & tz code can be built and run under Windows and am happier when it does. Now for the horror story - for various reasons (which are not up for argument and I know all the pros and cons) I am still supporting MSVC 6! And don't have any immediate plans to move to more recent versions of MSVC (hoping to move to GCC/MinGW instead). Just so long as the code uses typedefs for the various integer sizes and doesn't have piles of "long long" etc in the C files I'm quite used to providing a header patch for whatever is the spelling-du-jour for "32 bit unsigned int". For what its worth, I've always been intending to share the above C++ code, along with my earlier mentioned enumeration of time zones (giving each a small integer instead of a string name) but simply haven't so far (and it is very old code!) - if anyone is interested I'll tryto figure out a way to share it sensibly. Regards, Stephen Goudge Engineer 390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU T +44 (0) 191 420 3015 F +44 (0) 191 420 3030 W www.petards.com This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. Petards Group plc is registered in England & Wales. Company No. 2990100 Petards Limited is registered in England & Wales. Company No. 2301063 Petards Joyce-Loebl Limited is registered in England & Wales. Company No. 2170100 Registered Offices: 390 Princesway, Team Valley, Gateshead, Tyne & Wear NE11 0TU, UK. ___________________________________________________________________________________________ This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________
participants (5)
-
Brian Inglis -
Goudge, Stephen -
Jonathan Leffler -
Paul Eggert -
random832＠fastmail.us