## TeX on Windows: TeX Live versus MiKTeX revisited

On Windows, users have two main choices of TeX system to install: TeX Live or MiKTeX. I’ve looked at this before a couple of times: first in 2009 then again in 2011. Over the past few years both systems have developed, so it seems like a good time to revisit this. (I know from my logs that this is one of the most popular topics I’ve covered!)

The first thing to say is that for almost all ‘end users’ (with a TeX system on their own PC just for them to use), both options are fine: they’ll probably notice no difference between the two in use. It’s also worth noting that there is a third option: W32TeX. I’ve mentioned this before: it’s popular in the far East and is where the Windows binaries for TeX Live come from. (There’s a close relationship between W32TeX and TeX Live, with W32TeX more ‘focussed’ and expecting more user decisions in installing.)

Assuming you are going for one of the ‘big two’, what is there to think about? For most people, it’s simply:

• Both MiKTeX and TeX Live include a ‘full’ set of TeX-related binaries, including the engines pdfTeX, XeTeX, LuaTeX and support programs such as BibTeX, Biber, MakeIndex and Xindy.
• The standard installer for MiKTeX installs ‘just the basics’ and uses on-the-fly installation for anything else you need; the standard install for TeX Live is ‘everything’ (about 4.5 Gb!). Which is right for you will depend on how much space you have: you can of course customise the installation of either system to include more or less of the ‘complete’ set up.
• MiKTeX has a slightly more flexibly approach to licensing than TeX Live does: there are a small number of LaTeX packages that MiKTeX includes that TeX Live does not. (Probably the most odious example is `thesis`.)
• TeX Live has a Unix background so the management GUI looks slightly less ‘standard’ than the MiKTeX one.
• TeX Live has a strict once-a-year freeze,which means that to update you have to do a fresh install once a year. On the other hand, MiKTeX versions change only when there is a significant change and otherwise ‘roll onward’.

So the decision is likely to come down to whether you want auto-installation of packages. (If you do go for MiKTeX on a one-user PC, choose the ‘Just for me’ installation option: it makes life a lot simpler!)

For more advanced users there are a few more factors you probably want to consider

• TeX Live was originally developed on Unix and so is available for Linux and on the Mac (and other systems) as well as Windows; MiKTeX is a Windows system so is (more-or-less) Windows-only. So if you want exactly the same set up on Windows and other operating systems, this of course means you need to use TeX Live.
• Both systems have graphical management tools as well as command line interfaces. They have a lot in common, but they are not identical (in particular, MiKTeX tends to emulate TeX Live command line interfaces, but the reverse is not true).
• The engine binaries in TeX Live are (almost) never updated other than in the yearly freeze period, meaning that for a given release you know which version of pdfTeX, etc., you’ll have: MiKTeX is more flexible with such updates. (At different times, one or other of the systems can be more ‘up to date’: this is not necessarily predictable! The W32TeX system often has very up-to-date testing binaries.)
• The two systems differ slightly in handling how local trees are managed (places to add TeX files that are not controlled by the TeX system itself). TeX Live automatically expects `<installation root>/texmf-local` to hold system-wide ‘local’ additions and `<user root>/texmf` to hold per-user additions, whereas MiKTeX has no out-of-the box locations, but does make it easier to add and remove them from the command line. MiKTeX also makes it easy to add multiple per-user trees, whereas for TeX Live there’s more of an assumption that all user additions will be added in one place. (This makes it easier in MiKTeX to add/remove local additions by altering a setting in the TeX system rather than deleting files.)
• TeX Live has a team doing the work; MiKTeX is a one-man project. This cuts both ways: you know exactly who is doing everything in MiKTeX (Christian Schenk), and he’s very fast, but there is more ‘spread’ in TeX Live for the work.
• For people wanting to step quickly between different versions of TeX system, the fact that TeX Live freezes once a year makes life convenient (I have TeX Live 2009,2010, 2011, 2012, 2013, 2014, 2015 and 2016 installed at present, plus MiKTeX 2.9 of course!) You can switch installations by adjusting the `PATH` or by choosing the appropriate version from your editor, so have a ‘fall back’ if there is an issue when you update.
• TeX Live has build-in package backup during maintenance updates.

## TeX on Windows: MiKTeX or TeX Live

Around two years ago, I wrote a short post comparing MiKTeX and TeX Live for Windows-based TeX users. Looking at my log files, this topic is perhaps the most common search term that brings people here. As such, I think it’s time to revisit the question and bring what I said before up to date.

On Windows, there are two actively-developed TeX systems with similar coverage: MiKTeX and TeX Live. Before I look at the comparison, a reminder that they are not the only choices. W32TeX is popular in the far east, and as well as being a TeX system in its own right is the source of the Windows binaries for TeX Live. There are also the commercial BaKoMa and VTeX systems (although whether anyone can get hold of the supplier of the latter is another question). However, for most users it comes down to a choice between the ‘big two’.

The good news is that there is a lot of similarity between the two systems, so for most users both systems are equally usable. However, there are differences and depending on what you need these might be important.

• The standard settings install everything for TeX Live, but only a minimal set of packages for MiKTeX. MiKTeX will then install extra packages ‘on the fly’, while TeX Live does not (there is a package to do that in TeX Live, but it’s aimed at Linux). Install-on-the-fly is useful if space is limited, but is more problematic on server set ups. So this is very much a feature who’s usefulness depends on your circumstances. Of course, there is nothing to stop you using MiKTeX and installing everything.
• The xindy program is only available in TeX Live. For those of you not familiar with it, xindy is an index-processor, and is much more capable of dealing with multi-lingual situations than MakeIndex. If you need xindy, TeX Live really is the way to go.
• MiKTeX is very much a Windows tool set, while TeX Live comes from a Unix background. This shows up from time to time in the way TeX Live is administered, and the fact that the TeX Live GUI is written based on Perl rather than as a ‘native’ Windows application.
• As TeX Live is the basis of MacTeX, and is the TeX system for Unix, if you work cross-platform and want an identical system on all of your machines, then TeX Live is the way to go.

## WinEdt version 6

WinEdt is a popular (La)TeX editor on Windows. A new major release, version 6, has just appeared on the WinEdt homepage. The interface has received a lot of attention, with new icons and menu arrangements. One thing that a lot of people have been hoping for is UTF-8 support, but the release notes say

Avoid sending major feature requests: they will have to wait for version 6.1 (unicode, folding and all)!

So for the moment people who need UTF-8 will have to look elsewhere. Another point to note for users of version 5.5 is that this is not a free upgrade (WinEdt is shareware).

## TeX Live on Windows

As I posted earlier, the upcoming releases of both MiKTeX and TeX Live have very similar sets of features on Windows. I’ve just stumbled upon something that points up the slight differences that exist, even though this one is a bit complicated.

To detect what system is being used, for things like shell escape tricks, there is a LaTeX package called ifplatform. However, this only works on Windows if MiKTeX is being used. The reason is that while TeX Live aims to be as similar as possible across platforms, MiKTeX can adopt a different approach and stick to Windows conventions. Most of the time, this is transparent but it shows up if you use the `-shell-escape` option for either system and try to do some testing. Inside ifplatform, you’ll find the lines:

```\edef\ip@sig{write18-test-\the\year\the\month\the\day\the\time}
\edef\ip@win{'\ip@sig'}
\immediate\write18{echo \ip@win >"\ip@file"}```

The idea is that the text written to the temporary file will be different on Windows to on a Unix-like system. MiKTeX will retain the single quotes around the test data:

`'write18-test-20098231074'`

whereas Unix-like systems will not:

`write18-test-20098231074`

But try using ifplatform with TeX Live on Windows and the test fails. First, no test file gets written at all: a bit of hacking leads to the change of the write line to

`\immediate\write18{echo \ip@win > \ip@file}`

and then at least the first step works. However, the test file now looks like a Unix one (with no quote marks), and ifplatform gets things wrong. So for the moment the only thing to do is create a stub package file and use it, something like:

```\ProvidesPackage{ifplatform}[2007/11/18 v0.2  Testing for the operating system]
\newif\ifshellescape\shellescapetrue
\newif\ifwindows\windowstrue
\newif\ifmacosx
\newif\iflinux```

I’ve reported the problem to Will Robertson, and hopefully a solution which really tests the OS rather than the TeX system can be found. However, it is a reminder that even with very general feature sets, the two major TeX distributions still act differently in some respects when used on Windows.

## Cross-platform working

As many people will know, the CTAN team have come up with the idea of having TDS-ready zip files for packages. The idea is that you can just download the zip into your local TeX directory, unzip it and run texhash, with no TeX-based unpacking or document compilation.

That’s all fine when it works, but I’ve recently had a bit of trouble making zips at my end. My favoured tool for doing that has tended to be 7-Zip. However, it was pointed out to me last week that the resulting zip files are not quite right. On Unix systems, the command `unzip -xa` will convert line endings to the system convention (LF only), even if they come from Windows (LF-CR endings). However, this requires that the zip identifies text files, and 7-Zip marks everything as binary!

I did a bit of hunting around, and found Info-ZIP, where after a bit of hunting about you can find `zip` and `unzip` binaries for Windows. These give me Unix-like capabilities on Windows, so I can make the appropriate files, alter line endings on zipping/unzipping and check the results.

That led me to take another look at the batch file I use each time I release something to CTAN: doing it by hand is an unreliable business! I’ve reworked it quite a bit, to generalise everything and also add a few tweaks. For anyone interested, the file is available here. It’s called make, so that you get Unix-like abilities on Windows. The file has to be customised for each package I write, but most of this version is generalised, and can be altered using a few settings.

```set AUXFILES=aux cmds dvi glo gls hd idx ilg ind ist log los out tmp toc
set CLEAN=bib bst cls eps gz ins cfg pdf sty tex txt zip
set DOCEXTRA=\AtBeginDocument{\OnlyDescription}
set INDEXFILE=gglo
set PACKAGE=achemso
set PDF=%PACKAGE%
set TDSROOT=latex\%PACKAGE%
set TEX=achemso-demo
set UNPACK=%PACKAGE%.dtx```

Anyone at all familiar with batch files will see that this is a block of environmental variables: in this case, these are the settings for my achemso package. Most are pretty obvious settings, but in case anyone wants to use the file for their own purposes:

• `AUXFILES` File types to delete after every run: throw away files.
• `CLEAN` File types deleted only if make clean is run: useful stuff.
• `DOCEXTRA` Inserted when creating documentation, can be anything. I don’t typeset the code for my packages in the release documents, hence the `\OnlyDescription` setting.
• `INDEXFILE` This is always `gglo` for documents using the `ltxdoc` class, but is `l3doc` if using the LaTeX3 class `l3doc`.
• `PACKAGE` Pretty obvious, the bundle name!
• `PDF` The names of PDF files to add to the documentation part of a TDS zip. By having this as a setting, special effects (demo documents, for example) are possible.
• `TDSROOT.` Almost always as given for a LaTeX package.
• `TEX` A list of .tex files to copy into the TDS archive: to avoid any testing files, not all .tex files are copied.
• `TXT` The names of text files to copy to the documentation directory
• `UNPACK` The file(s) to run to unpack the package. I use .dtx files that are self-extracting, but the traditional method is to have a separate .ins file.

If the batch file proves useful to enough people, I might write some proper documentation and do a bit more generalisation.

With all of that in place, I can hopefully keep Unix-based LaTeX users happy without too much work!