[DMcCunney]

Originally Posted by Katsunami

When writing a C# application to run under Mono, it basically is a Linux application, so it's indeed much easier to call a Linux executable of Pandoc. If you're going to run the Windows version, you'd need to run it on top of Wine.

Yep.

(Does a Windows C#/.NET application still need Wine+Mono installed, or can it now just run on top of Mono, just like a Java application runs on top of the Java VM? Don't know...

AFAIK, you should be able to run a C# application on Linux with just Mono, since the .NET runtime Mono implements actually executes the code. The C# code should be portable. You shouldn't need Wine in the mix.

I never bothered trying to run Windows-stuff on Linux, but I do run the Cygwin command line on Windows because I just know the Linux/Unix command line _much_ better than the long-winded, overly verbose Powershell.)

I used to run Cygwin but got cured of it. (I also ran AT&T's U/Win environment, which was an attempt to do the same thing that Cygwin did, developed by Dr. David Korn, the author of the Unix Korn Shell.)

Cygwin is an attempt to port the Gnu Linux toolchain to Windows, particularly the GCC compiler suite. The Cygwin developers encapsulated a subset of the POSIX API in the Cygwin1.dll file. A lot of Linux code builds "out of the box" under Cygwin because it links against the Cygwin DLL and sees the *nix system calls it needs.

That's fine if you want to develop code that will run under Linux on Windows, because you can set GCC to cross-compile to a Linux target. But you pay a performance penalty compiling for Windows because some things in *nix don't exist in the Win32 API, like fork, and there is overhead in translating the code to something that can run.

In addition, the Cygwin environment from a command line is different from Windows.

Back in the MSDOS days, I ran a package called the MKS Toolkit. I had a Unix machine at home (an AT&T 3B1) before I got a PC running DOS, and I wanted DOS versions of Unix commands. The Toolkit implemented all of the Unix commands that made sense on a single-tasking, single user OS like DOS. In particular, it offered a full version of the vi editor, and an implementation of the Korn shell that had everything save asynchronous sub-processes, because DOS didn't do that.

I had the Toolkit installed in fullest Unix emulation mode. Installed that way, when DOS was booted, the boot shell was the Toolkit INIT.EXE program. Init ran and printed Login: on your screen. You entered a userid and optional password. The userid was checked against a Unix compatible /etc/passwd file, and if a match was found, it changed to whatever was specified as that user's home directory, and ran whatever was specified as that users shell.

I made use of this. I had IDs that ran the Toolkit Korn shell, the shareware 4DOS COMMAND.COM replacement, vanilla COMMAND.COM, and the DesqView multi-tasking GUI. Exit the shell, and control returned to INIT, which printer Login: again. I could change environments without rebooting. (I kept the setup when I moved to Wi3.X. The default shell for Win3.X was Program Manager, but you could change that in the SYSTEM.INI file. I had Toolkit IDs that ran Win3.X using alternate shells. Worked fine.)

But the MKS Korn shell used Unix style command lines, where / was the directory separator, and - was the option delimiter. DOS used \ and / for those. The Toolkit provided a SWITCH utility that could change DOS's idea of what those delimiters were, and once - was the option delimiter, you could use / or \ as the directory separator. Unfortunately, some DOS programs didn't look at what DOS thought those chars were, and hard-coded \ as directory separator and / as option delimiter, so I had to wrap them in Korn shell aliases to run SWITCH to reset things on entry and exit.

Windows retains DOS usage, the same problems affected Cygwin under Windows, and similar work-arounds were required.

These days, I run versions of the *nix commands compiled to use Windows runtimes instead of Cygwin. There are several variants available. The current set is part of Git for Windows, which includes the Git DVCS and the standard Gnu Linux commands, including the Bash shell.

And Win10's Creators Update includes an optional package. Developers at Canonical, Ltd, Ubuntu's parent, have created libraries that let you run Linux command line apps under Win10. The original version was Ubuntu specific, but it's been expanded to include Fedora and Open SUSE. I can run a Bash command line under Win10 and use apt-get to install Linux utilities for use under it. And you can apparently run at least some Linux GUI apps if you run a Windows based X-server, though I haven't tried to.) You have the same issue that you are in a different environment, and calling Windows stuff from the Linux subsystem and vice versa takes fiddling, but you can.
______
Dennis