'fork' and signals are so "Unixy" - Minix

This is a discussion on 'fork' and signals are so "Unixy" - Minix ; I'm from the Windows programming world and find 'fork' and signals kinda foreign. I know what they do, but I prefer the process model and event subsystem of Windows. I wish Minix would do something similar to Windows in those ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: 'fork' and signals are so "Unixy"

  1. 'fork' and signals are so "Unixy"

    I'm from the Windows programming world and find 'fork' and signals
    kinda foreign. I know what they do, but I prefer the process model and
    event subsystem of Windows. I wish Minix would do something similar
    to Windows in those two regards rather than labeling itself "just another
    Unix" which I think it does if it carries over too many Unix programming
    paradigms. To me, if I see SIGanything in code, that equals Unix rather
    than anything new & improved (it also says to me, non-portable).

    I could say similar things about X-Windows. I don't particularly like a
    lot about the Windows GUI API, that is until I look at the X-Windows
    stuff and then I count my blessings!

    Tony



  2. Re: 'fork' and signals are so "Unixy"

    > I'm from the Windows programming world and find 'fork' and signals
    > kinda foreign. I know what they do, but I prefer the process model and
    > event subsystem of Windows. I wish Minix would do something similar
    > to Windows in those two regards rather than labeling itself "just
    > another Unix" which I think it does if it carries over too many Unix
    > programming paradigms. To me, if I see SIGanything in code, that
    > equals Unix rather than anything new & improved (it also says to me,
    > non-portable).


    These interfaces are defined by Posix and they are meant to improve
    portability. Since all Unix-like operating systems support this API,
    portability of programs written for it is actually very good. You can
    even compile these programs for Windows, for which Posix
    implementations are also available (such as Cygwin).

    The API doesn't tell you much about the OS though. You can make
    something new&improved without changing the API. In fact this is what
    Windows also did multiple times: the API of current Windows versions is
    still a superset of that of Windows 95, even though they changed a lot
    underneath.

    Changing the API everytime you make a new OS means it takes a lot of
    time to port programs to it, resulting in fewer applications being
    available, resulting in the OS not becoming popular.

    If you want an open source OS similar to Windows you could take a look
    at ReactOS, which aims at implementing the Win32 API (but AFAIK isn't
    very mature yet).



  3. Re: 'fork' and signals are so "Unixy"


    Tony wrote:
    > I'm from the Windows programming world and find 'fork' and signals
    > kinda foreign. I know what they do, but I prefer the process model and
    > event subsystem of Windows.


    There's one exercise question in the minix book that says something
    like this: windows doesnt fork processes. use your brain to to figure
    out what it does instead. I've not been able to come up with an answer.
    Clearly there needs to exists some kind of a mechanism to enter new
    processes into the process table; but who triggers such insertions?
    other processes? what code do these newly inserted processes run? and
    who owns them?

    thx,

    martin


  4. Re: 'fork' and signals are so "Unixy"

    > > I'm from the Windows programming world and find 'fork' and signals
    > > kinda foreign. I know what they do, but I prefer the process model
    > > and event subsystem of Windows.

    >
    > There's one exercise question in the minix book that says something
    > like this: windows doesnt fork processes. use your brain to to figure
    > out what it does instead. I've not been able to come up with an
    > answer. Clearly there needs to exists some kind of a mechanism to
    > enter new processes into the process table; but who triggers such
    > insertions? other processes? what code do these newly inserted
    > processes run? and who owns them?


    It uses the CreateProcess API function instead:
    http://tinyurl.com/2d4m

    Basically this function combines fork with exec, including also
    features related to security and redirection. Combining this in a
    single function call makes it more efficient, as there is no need to
    copy a process which would be overwritten afterwards anyways.

    Also note that in Windows using multiple threads is much more common
    than using multiple processes, as is more often done in Unices. This is
    probably because Windows provides kernel threads and (almost?) the
    entire API is threadsafe (much unlike Posix). Therefore CreateThread is
    also used in situations where in Posix one would be likely to use fork.

+ Reply to Thread