|
From: KJK::Hyperion <no...@li...> - 2002-06-02 15:11:16
|
At 13.16 30/05/2002, you wrote: >Cygwin would *almost* be an solution if win's console werent utterly >broken (by design). Please do not try to argue with me on that, repeat >after me, win's console (as it is implemented today in 2k) is UNUSABLE for >a command line power user. (Selection behaviour, size change restrictions >are the major showstoppers). Not only from the user perspective, also from a programmer's point of view. The most important missing features are the slave-master model, and a single stream, for both data and control codes (the only advantage in using two separate streams is being able to print binary data... useless). Even DOS was better in this respect, when you could easily filter the console operations by simply hooking an interrupt, and embed ANSI codes in your batch files and printf strings for colored text and such >I certainly wouldn't mind an open OS that can run M$-Ware, but if in that >OS the concious design decision is made that all apps developable for that >OS must also run under Windows - i.e. it is conciously limited in certain >areas - I certainly wonder about its usefulness. A "windows compatibility >certification mode" (or just "win32ss visible only mode"), maybe >per-process, would certainly be useful - but if I want to do "cmd.exe -c >type diskimage > \dev\fd0" why won't you let me? or copy \dev\zero A:. man CreateProcess. ssh -n foo WinWord.exe \\bar\usr\home\bill\baz.doc. The possibilities are endless. The last example is especially interesting: it starts Word on the remote machine foo through ssh, using the local display, opening a file from bill's home directory, on the remote machine bar, through SMB >BTW: If anyone feels like seriously thinking abouth some of these >'limitations' I could certainly flesh out a wishlist for 'doze from an >unix administrator's point of view. I'm interested. I have a few in mind, but I want to hear the opinion of someone more experienced first |