Windows loaders packaging draft

Exception for precompiled windows loaders

Short version

For the Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries section

• Windows wrapper executables for scripts may be allowed. See Precompiled Windows Script Wrappers for details

Precompiled Windows Script Wrappers

Longer version for its own page.

Windows does not support the shebang line like Unix systems do. For this reason, Windows has an idiom of creating wrapper executables for scripts. These wrappers check what name they were invoked under and then attempt to launch an interpreter with the script in question. For instance, a python loader may be called foo-app.exe. When run on Windows, it will try to run a python interpreter from the Windows PATH on the file foo-app.py in the same directory as the wrapper.

In some cases we may want to package software in Fedora which contains generic wrappers. The purpose here would be so that developers can create a script on Linux but package it up for use on Windows. The software package in Fedora would allow the developer to copy the generic wrapper into their software to run their script when installed on Windows. It therefore makes sense for us to ship those compiled wrappers in our package.

Does the following make sense? I don't know Windows, just piecing together the issue from an IRC discussion. Not sure precisely why loading the CRT library at the bottom would cause conflicts when, at the same time, mingw says when you cross-compile a program, that program should work on any system, no matter what version of MSVCRT is installed.

Now, as to why those wrappers need to be pre-compiled as opposed to our cross-compiling them with mingw. These wrappers are going to need to link against a C library for Windows (known as a CRT -- C-RunTime). Mingw does not contain a CRT.dll so if we were to compile the wrapper script using mingw, the CRT would need to be linked dynamically. Oftentimes, the script interpreters installed on Windows are also dynamically linked. If the wrapper is dynamic, Windows will load the most recent CRT.dll that it has and then run it. When the wrapper tries to load the dynamically linked interpreter, the interpreter may need a different version of the CRT library than what was loaded for the wrapper. When this happens, Windows will load a second version of the CRT for use by the interpreter. As the interpreter runs, it will likely use some of the same internal CRT global variables as the wrapper (for instance, the FILE * to stdin and stdout; allocating and freeing memory). This will cause an error of some sort at runtime. Linking the wrapper statically avoids this as Windows will keep the wrapper's copy of the CRT library from conflicting with the symbols from the dynamically loaded CRT.dll.