Supporting Windows users

Many “open” projects are developed mainly by people using Unix-based operating systems (Linus, MacOS X, OpenBSD, etc.). This sometimes leads to a rather awkward situation for Windows users. Many of the tools that are assumed to be available (GCC, make, grep, …) simply are not. TeX is luckily cross-platform, and recent versions of TeX Live work hard to work on Windows as well as on *nix systems. However, that can still leave a few issues.The LaTeX3 experimental code has a series of test files, make scripts and so on, to aid development. However, these only work if things like make and bash are actually available. So I’ve recently added a set of batch files to the source store, which hopefully do basically the same thing but using Windows tools. I’ve had to require Perl for the test scripts, as these need to be parsed and re-formatted. The batch files also need a command-line zip program: I tend to use 7-Zip. Hopefully, though, these are not too much to ask for!

In the longer term, LuaTeX should mean that auxiliary stuff can be done using Lua, as it will be available cross-platform. However, it could be many years before we reach that state!

7 thoughts on “Supporting Windows users

  1. Hi Joseph,

    1) My experience makes me suggest that it might be simpler in the long run to simply provide/require make and bash. Especially make. There is no substitute.

    2) 7-zip is far from universal. Plain zip is the only thing that is even close.

  2. Hello Karl,

    On the “make” issue, I’m not sure I see this. I think I’ve got pretty close with my batch files. Of course, the underlying approach is very different as make has the concept of a chain of events, which have to be done by hand with a batch file. My starting point was essentially “do as much as possible without needing extra tools”.

    For zips, I use 7-Zip so I know what to look for. I’m happy to add detection for other zip programs. Not sure what you mean by “plain zip”: the original is PKZIP, but you have to pay for it. The other strong contender, WinZip, is also paid-for software, and as 7-Zip is free I’m less inclined to pay up! I guess I could download the trials to get the appropriate settings (locations and file names I can guess, it’s more the correct flags to get compression to work correctly). The integration of zip capabilities into the Windows shell (but only graphically) means that there is not likely ever to be a “standard” add-on. So I have to work with what I’ve got. I should add that the other reason for favouring 7-Zip is it has about the best coverage of other formats on Windows. Okay, no SITX and most of the archive types are extract-only, but that usually does me.

    (Thinks: did you mean the ZIP file *format* as opposed to the *program*? The whole reason for needing a zip program is to make CTAN archives, which have to be in ZIP format.)

  3. I should add that I wonder if the Perl script can be replaced by some clever TeX programming. If so, that would drop one issue. Can’t do much about making ZIPs with TeX, though.

    • No doubt about it, most obviously as part of Cygwin. However, the point for me was that you can’t expect most Windows users to install all of that (I haven’t, for a start!). Batch files can get you a long way using native tools (at least with the extensions in XP/Vista/Win7), and so I’ve tried to only require extra things when necessary. I still wonder if the tests could be parsed by TeX: somewhat challenging, perhaps.

  4. Have you considered MSYS? Much smaller than Cygwin and prepackaged. But of course there is nothing wrong with batch sctips, I use them all the time. The trouble is that you might end up maintaining a parallel subproject just for the infrastructure, once the system grows big enough. From that point of view, LuaTeX might be a better option in the long term, indeed. It is already included in TeX Live (and Perl as well, btw) and should soon come to MikTeX too.

  5. MSYS is smaller than Cygwin, but it still is an extra “thing” to do stuff that Windows can manage on its own (at least in this context). I’ve not looked in enough detail at recent TeX Live releases to know that it includes Perl: on Windows, MiKTeX is still choice one, I think.

    At the moment, the stuff I’m worrying about probably has a rather small audience (Morten Høgholm when he’s at work plus me, that I know of). So I don’t have to be too concerned. In the future, who knows what will happen. We still have to see if LaTeX3 goes beyond some interesting ideas: I’d hope so, but until it happens you just never know.

    In the longer term, I entirely agree that LuaTeX is going to be the best plan. But that really does depend on the spread of LuaTeX. Other members of the LaTeX team certainly have older TeX systems, and so we can’t just decided to use Lua at the moment. Unless everyone can use it, the “parallel paths” issue is still there, and for the moment at least all of the *nix people are happy with the Makefiles. So whatever I do means some work for me. That said, now I have the batch files working reasonably well I’m hopefully not looking at too much to do at any point.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.