(Translated by https://www.hiragana.jp/)
Christian Schenk : MiKTeX Development
The Wayback Machine - https://web.archive.org/web/20050924175858/http://dojo.miktex.org:80/blogs/christian_schenk/archive/category/1001.aspx

MiKTeX Development (RSS)

pdfTeX 1.30 won't be integrated into MiKTeX 2.4

The pdfTeX team has announced version 1.30.3 of the pdfTeX engine. I have decided against integrating this version into the stable MiKTeX 2.4 distribution.

MiKTeX 2.5 Beta 1 (source code)

I have released the MiKTeX 2.5 Beta 1 source code (see announcement). The package includes the command-line version of the package manager.

This is not a release for Windows operating systems. The source code is meant to be compiled on GNU systems.

Help wanted: building/testing MPM on Un*x machines

I am looking for volunteers to help building/testing the package manager on Un*x systems. The job description is here:

http://sourceforge.net/people/viewjob.php?group_id=10783&job_id=22872

Porting the package manager (Contd.)

I have released a snapshot of the current MiKTeX 2.5 source tree:

http://prdownloads.sourceforge.net/miktex/miktex-2.5.2045-snapshot.tar.gz?download

The source tree can be used to build the package manager (MPM) for Un*x systems. The prerequisites are:

  • ANSI-compliant C++ compiler (e.g, g++ 3.x)
  • CURL libraries

Porting MFC (Windows) applications to Linux?

Now that the commandline-version of the package manager is near completion, I wonder how complicated is it to port the Windows (MFC) version to Linux?

I take into consideration these strategies:

  1. Reimplement the application in C# (.NET), i.e., port it to Mono.
  2. Rewrite the MFC application using one of the free portable GUI toolkits:
    • It seems that wxWidgets (fka wxWindows) would be the right choice, since it resembles the MFC framework.
    • Qt is a well designed toolkit. But it is unclear whether the Windows version of Qt will be released under GPL.
    • GTK+ is released under LGPL and claims to be object oriented, though it is written in C.

Porting the package manager

I have completed refactoring the MiKTeX core library. The library now compiles on Linux systems.

Next comes the package manager library. Challenges in this area are the following:

  • Internet protocols (HTTP, FTP)
  • cabinet files

Currently, the library uses Windows APIs to access the Internet and to read cabinet files. In order to make the library portable, I will refactor it to use

The refactoring will take a month or two. Once completed, we have the command-line version (http://www.miktex.org/manual/mpm.html) of the MiKTeX package manager ready to be run on Linux, i.e., teTeX/TeXLive users will be able to download and install packages from the MiKTeX package repository.

MetaPost 0.901 available

I have uploaded the new MetaPost binaries to the SourceForge file server:

http://prdownloads.sourceforge.net/miktex/metapost-0.901.zip?download

MetaPost 0.901

The MetaPost team has released MetaPost 0.901. This version seems to be ok, i.e., the tests now succeed. I will make available executables for MiKTeX 2.4 asap.

MetaPost 0.9 (Contd.)

I have compiled MetaPost 0.9 for MiKTeX 2.4. Unfortunately, the test suite (mptrap) fails with the new executable. Maybe the suite is broken. I have reported the problem to one of the MetaPost developers.

MetaPost 0.9

Today the MetaPost team has announced MetaPost 0.9. I am currently downloading the tar file. Tomorrow I will take a look at the source code. If possible, I will make available binaries for MiKTeX 2.4. We shall see...

MiKTeX 2.5 development has started

MiKTeX 2.5 developmet has started in December. According to the roadmap, the first step is to redesign the internal interfaces (aka refactoring). The outcome will be a portable set of components. Portable in the sense that it will be easy to build the components for other systems.

I am currently working on the core component (MiKTeX-core*.dll). The core component handles

  • file searching
  • running secondary processes
  • reading configuration files

System-dependent features in this area are:

  • reading directories
  • reading/writing memory-mapped files
  • threads

There are well known design patterns which help to separate system-dependent code. Implementing these design patterns is an interesting job which will keep me busy the next few months.

Starting mgs.exe at the DOS-Prompt

Every once in a while I receive the following request: "Please, make mgs.exe runnable at the DOS-prompt". You should know that mgs.exe is a special version of Ghostscript, meant to be called internally by MiKTeX applications (such as Yap). If you start mgs.exe at the DOS-prompt, the following will happen:

> mgs
MiKTeX GPL Ghostscript 8.15: Can't find initialization file gs_init.ps.

That's because mgs.exe doesn't use the original registry keys and environment variables. For example, mgs.exe queries MIKTEX_GS_LIB instead of GS_LIB. You can start mgs.exe at the DOS-prompt if you set MIKTEX_GS_LIB as follows:

MIKTEX_GS_LIB=C:\texmf\ghostscript\base;C:\texmf\fonts