hi fabian,
let me tell a few words about the story leading to this port. sometimes
i will post the (really) long version here, but for now only the highlights:
we were using mks-toolkit for a long time to run an application coming
from aix/hpux/solaris to windows. in 2009/2010 mks changed its
conditions in a way that we had to look for a replacement.
important points were:
o to have a solutions we can expect to be available for many
years.
o since this shell framework controls native win32 applications,
a "cheese cover" approach like e.g. cygwin does not fit our
needs.
o the shell must be as ksh compatible as possible.
no big deal i thought... but google did not find any ksh.exe beyond the
frameworks mentioned above. tests with cygwin showed up a lot of problems.
the gnuwin32 utilities may not be the most current versions but they
seemed to do their job. the only missing thing was a korn shell.
so the crazy idea came up to look for sources of a ksh and try to port
it to windows. after some search i found mksh (never heared about it
before - shame...). one goal was so stay independent and not to rely on
a compatibility library.
looking at the current state of this project i can say that i did not
start basing it on a compatibility library. but there was (no surprise)
a lot of compatibility stuff to take care about. it was obvious to keep
this stuff separate from the core code of mksh. so i came out with
something like my own, small compatibility library. but core stuff like
fork() or sigchld (in progress) is still implemented directly in the shell.
for me it would be no bad thing to have or use such a library. the
question is how much it isolates applications built against it from
windows itself and other native win32 applications. here i agree with
thorstens "picture", showing mingw very near to native.
about the utils: at the moment i use a mix of mostly gnuwin32, a few
unxutils and a few self-written ones. e.g. rm is self written because i
found no rm implementation that was able to detect and not to follow(!)
windows junctions and/or symlinks. ln (-s) too.
i spent some time to get information about how to create a mingw build
enviromnent. may be i looked at the wrong places but i found nothing
looking like success within a few days. so it seemed easyer to me to
rewrite a few tools with the minimum, classic unix option set.
thats the point where fabians post opened a new perspective (thanks): up
to now mingw-w64 was not on my radar. i will take a look on it. it
doesnt look like the tools coming with it will be the right ones for a
native win32 environment. but this should definitely help me to create a
mingw build environment.
but - is mingw still maintained? do have current mingw versions
knowledge about e.g. windows symlinks? i'll see...
anyway - i agree that a shell alone makes no sense. i am still tuning my
personal set of utils. it does not really matter how old they are, what
kind of icon they have or how many dlls they use. once organized in a
directory structure and zipped, this things are out of focus. the
important point is that they do their job and scripts in this
environment run as expected.
if i found a combination that satisfies my needs you will here from me.
--lan
