Am 29.07.2013 10:03, schrieb Fabian Greffrath:
Wow, I believe implementing fork() is one major step in porting a Unix shell to Win32?
yes, for sure. "normal" applications do very few things between fork and exec (if any). it is easy to replace this few things by windows native stuff. but the shell does a bit more or (depending on the script) does the whole job in a forked subshell.
when starting i thought about using threads instead of emulating fork. thats something we did when porting other applications to win32. starting a new process on windows uses much more ressources as on unix. thus, threads would have been faster than starting 2 new processes on each fork/exec. but this would have caused big changes in the shell code.
since i was used with shared memory i had the idea to insert a layer below malloc, place the complete heap stuff there, copy and map it into the "forked" process at the same address. with the malloc replacement nedmalloc i found what i was looking for. i got it doing what i wanted with very few changes. the very clean and structured memory management in mksh made it easy. this initial code (or hack) is working in such a good way that i delayed rewiewing it time by time. there are things i would (and will) implement in a different way with todays knowledge.
Your compatibility library is what can be found in the liblan directory? Ever considered extending this library so that the full set of shell utilities could be built against it?
definitely no. i use this liblan since >25 years and store all those (more or less...) useful functions one creates within a programmers life there to share it for internal use in our company. since i maintain the same application for unix and win32, there is some compatibility stuff there too. but typically not in a way that unix syscalls where emulated 1:1. i am allowed to release the parts needed for bulding mksh as open source. thus, the liblan provided here is only a subset.
when i started with porting mksh i made all the changes within the mksh sources. after some days of "wild hacking" in early 2010 i saw the first "$" instead of crashes :-) this was the point where i realized: hey - it could work. but the sources looked a bit desolate. i started consolidating my changes in mksh/win32.c. functions from liblan where used as needed.
then it came out that i have to (re)write some utilities (as mentioned). at this time i took things i need in mksh and the utilites from mksh/win32.c out to liblan/win32px.c. from that time on i tried to place additional compatibility stuff in win32px.c. e.g. the remote procedure calls for the signal handling are implemented there. the stuff to keep exec-chains linked to a parent pid (needed in ps.exe) is another example.
lets see in which directions the things go. for now it is not my goal to create another compatibility library. win32px.c just helps me to keep things easier.
i am not lucky with the way the mksh/win32 sources are organized actually. but on the other hand i had not the time for cosmetics and wished to release this first beta.
It (mingw) builds against the systems msvcrt.dll with header files constructed from reverse engineering, so it *is* a native build, but not the system's native compiler.
agree. --lan
