fpTEX: A teTEX-based Distribution for Windows Fabrice Popineau Sup´elec 2 rue E. Belin F-57070 Metz France [email protected] http://www.ese-metz.fr/~popineau Abstract This paper deals with the ins and outs of porting the widely used teTEX distribu- tion to the Windows environment. The choices made and difficulties experienced are related, a brief description of this huge distribution is given and the future work is sketched out. Motivation Some of the nicest features of emTEX, such as its dvipm previewer, were not available to Windows users. Context. More and more people need to use some Moreover, emT X’s author, Eberhard Mattes, never sort of Microsoft environment, perhaps because of E released his sources. office suite or the like, or because of management At the same time, MiKT X began to mature. staff decisions. Some of the greatest pieces of soft- E Christian Schenk, author of MiKT X, has followed ware have been developed on UNIX (or other oper- E a different way. He has designed a completely new ating system) well before the general availability of Win32-oriented T X distribution. Looking at his Windows. Thus, software such as T X should be E E work, I questioned the usefulness of porting Web2C available on Microsoft operating systems, natively to Win32, but there were some reasons to do so: ported, and compatible with implementations on other operating systems. TEX by itself is largely Compatibility. Having a Windows TEX distribu- platform independent but achieving complete com- tion based on exactly the same files as the UNIX patibility for an entire distribution is better. one means you can share resources. For exam- The Web2C TEX distribution is one of the great- ple, you can not only share texmf trees across est TEX implementations and has support for porta- the network but also configuration and format bility. Moreover, Web2C is the base of the widely files. used teTEX distribution for UNIX.NowthatUNIX Portability. Most of the ongoing developments and Windows can easily share files across the net- around TEX are done with UNIX Web2C (see work, thanks to tools such as Samba, it is most de- pdfTEXor"-TEX). Being able to share source sirable to have not a teTEX-like TEX distribution files means less efforts to compile a new release. for Windows, but the actual teTEX distribution for There is another consequence: on several occa- Windows. sions, it has proven to be useful to compile the source code on something really different from Free TEX for Windows. In the fall of 1997, when UNIX. Errors that do not show up on one plat- I began to port Web2C to Win32, one main TEX dis- form may do so on another one. tribution was available to Windows users: emTEX. This is still a great TEX environment but it was de- Usability. Lots of people are familiar with teTEX signed for MS-DOS first and then for OS/2.So,when under UNIX. Having the very same distribution Windows became 32-bit-aware,1 those MS-DOS ap- under Windows is a plus. plications could not benefit from the new 32-bit flat The plan. The porting tasks can be divided as fol- mode, or at least not optimally. The so-called DOS- 2 lows. Note, however, that the job was not formally extenders were not as smart as they are today. planned at all since it had to be done using mostly 1 In fact, even if Windows 9x can run 32-bit mode appli- spare time. So the project has followed a circu- NT cations, only the Windows incarnation of Windows is a lar technique, with some issues only being resolved true 32-bit environment; see section about the previewer 2 For example, support for long filenames was not avail- quite recently. Below is a very short description of able at first. the next sections. 290 TUGboat, Volume 20 (1999), No. 3 — Proceedings of the 1999 Annual Meeting fpTEX: A teTEX-based Distribution for Windows Command-line programs. The first goal was to { gsftopk and ps2pk to rasterize Type 1 have a tex.exe running under the Win32 API fonts to PK files (Application Programming Interface), the set of { mktex* support programs for generating functions that implement the kpathsea library. missing font files and fmtutil for building Compilation environment. teTEXusesapower- formats ful tool called autoconf. This tool relies heavily • a DVI file viewer based on xdvi, but adapted to on having a UNIX shell and lots of UNIX utili- Windows ties such as sed, grep, awk, and so on. Clearly, • packages found on the TEX-Live CD such as: this is not something easy to find and run under { dvipdfm, to convert DVI files to PDF Windows. { tex4ht and tth, to convert TEX files to Shell issues. Moreover, the source distribution uses HTML some shell scripts at run-time.Itisnotwise DVI to suppose that the end-user will have a UNIX { extra tools to deal with either files, shell on a Windows machine. PostScript files or fonts. • Operating system-specific. Some issues like find- extra packages found only on the Win32 section CD ing a replacement for file links or naming files of the TEX-Live : on the network have been solved recently. The { ttf2pk and ttfdump will handle TTF fonts question of using the registry is also mentioned. { hbf2gf will handle East-Asian fonts Previewer. No TEX distribution would be com- { gzip and jpeg2ps, which can be handy DVI plete without a previewer. So the port of • the teTEX texmf tree, which is not the least xdvi was contemplated. important part! Installation. This is the trickiest part. Binary dis- tributions were not common under UNIX but Command-line programs they are under Windows, and the installation The process. The Web2C distribution integrates process is very different. all TEX-related tools around one main library called Configuration. The process of configuring Web2C kpathsea. It was devised by Karl Berry to face is very simple because it consists mainly of edit- the growing number of environment variables needed ing text files or setting up environment vari- to set up a complete TEX distribution. Instead of ables. The teTEX distribution introduces a smart setting environment variables, the path values and tool to administer the system, and this task can many other constants are looked for in a configu- be rendered in a Windows-oriented way as well. ration file. This guarantees extensibility and is far Future work. There are many points that can be easier to maintain. enhanced and some will be done in the very near The second point is the process of compiling future. TEX itself. The Web2C distribution owes its name from the Web ! C translator that converts the orig- However, if tasks such as editing a text file, set- inal Web code to C programs. Basically, the follow- ting environment variables or unpacking an archive ing tools were needed: are usual in the UNIX world, they are not usual any- • a C compiler targetting the Win32 API and, more in the Windows, world where end-users expect if possible, supporting the standard C library automatic or point-and-click things to happen. So functions; the installation and configuration parts are very spe- • UNIX cific to Windows. some tools such as sed, grep and awk; • the Perl language, which has proven to be useful The contents of the distribution to put glue between many parts of the building Before discussing the porting issues, here is a brief process, due to the lack of a shell with real pro- outline of what is in the distribution: gramming capabilities under Windows. • Web2C base distribution: TEX, METAFONT, Choosing a compiler. The availability of GCC — METAPOST, DVIware and fontware tools or rather of a native Win32 GCC — under Windows is quite recent. Moreover, GCC in its Cygwin3 incar- • each TEX extension or package that is found in nation has some drawbacks under Windows: teTEX: 3 { "-T X, pdfT X, Ω (Omega) Most of the GNU tools have been ported to Win32 by E E Cygnus Software and their port is under the GNU Public { dvipsk and dviljk to print DVI files Licence. See http://sourceware.cygnus.com/cygwin/. TUGboat, Volume 20 (1999), No. 3 — Proceedings of the 1999 Annual Meeting 291 Fabrice Popineau • Every program is linked to a DLL (Dynamically • popen() is available only for command-line pro- Linked Library) that emulates UNIX calls; this grams but fails for graphical programs (the pre- slows down somewhat programs doing intensive viewer uses this call!). 4 file system calls, for example. • stat() fails to recognize directories if their name • At the time I began the Web2C port, this DLL has a trailing / . was not stable at all. All these problems have workarounds using the Win32 • GCC Benchmarks on the same computer using calls instead of the standard C calls. under Linux and the Microsoft compiler under NT have shown up to 20% less time on the same Compilation environment runs in favor of the Microsoft compiler.5 In order to make the build process safer and closer Thus, the Microsoft compiler was chosen. The gen- to what happens under UNIX, a number of decisions eral philosophy was to stick to the Win32 API as had to be made. much as possible and avoid any layer to handle the translation, which might alter performance. Makefiles. Every UNIX Makefile comes in a gener- Many of the auxiliary tools needed for the build ic shape, Makefile.in, that needs to be instantiated UNIX process were available either through the GNU- by the complex process of autoconf.The Win32 Cygnus project or from previous ports to MS- Makefile.in is assembled and processed by the m4 DOS; however, almost none of them were available macro processor to generate the actual Makefile natively ported to Win32.