Questions about windows support

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Feb 20 18:06:36 PST 2012


On Tue, Feb 21, 2012 at 02:00:20AM +0100, Adam D. Ruppe wrote:
> On Tuesday, 21 February 2012 at 00:37:33 UTC, H. S. Teoh wrote:
> >Weird. I guess I must be a very strange person, because I find that
> >my productivity soars at the command-line
> 
> Me too. Command line rocks, and bash is a fine shell.  (csh sucks
> though, why its the default on so many bsds is beyond me.)

Heh. I was enamored of tcsh for a great many years, possibly a decade,
until I finally decided bash's nice features outweighed its annoying
parts.


> What I'm talking about here is the underlying technology and ease of
> programming.
> 
> It isn't difficult to get a compiler on Windows and write code. You
> can use Visual Studio, or notepad, or anything in between.

Same with Linux, I thought? Although I mainly just use vim for
programming, so maybe I'm unaware of the full situation.


> You can write a lot of code easily, from 16 bit DOS programs (well,
> not anymore on 64 bit, but you could for a long, long time) up to gui
> apps, including doing console apps that have an api similar to vga
> text hardware.
> 
> On Linux, you have to worry about terminal escape sequences, libc
> incompatibilities, and all kinds of other stuff to write similar
> programs.

Terminal escape sequences?! You should be using libcurses or libncurses.
No wonder you had a bad experience. :)

But I agree with you though, that libc incompatibilities are really
really REALLY annoying. Like snprintf(NULL, 0, fmt, ...) working like a
charm in one libc, and segfaulting or returning garbage values on other
libc's. The C99 spec *does* specify how it should behave, but that
doesn't help when the libc is not 100% compliant. Besides, some parts of
C99 are really stupid anyway, like the half-hearted part with wchar_t.

Then you have libc's that are missing some convenient functions which
you then proceed to define, only to discover it fails to compile
elsewhere 'cos it conflicts with the system-defined function.

That's why I'm liking D a lot, in spite of it still being under
development and having nasty compiler/library bugs every now and then.
:) For all its current flaws, D does a wonderfully better job than C/C++
in so many places.


> Remember though, that this isn't about the shell or userland. I really
> like the Linux command line (though it isn't perfect... ever gotten
> "command line too long" due to how * is expanded by the shell? Ugh.).

Yeah I remember that. I thought they've since fixed it, though. That's
more a bash limitation than anything, AFAIK. Besides, what *were* you
trying to do with such a long command-line anyway? :-)


> But anyway I really like it, but the operating system isn't any easier
> to program for. Indeed, if you want to distribute your app, it is a
> lot harder due to compatibility.

Yeah, Unixland really works best with the "here's the source code,
compile it yourself" model, rather than with the Windows "here's the
binary executable" model. Gentoo's emerge is a step closer to making it
more accessible to end-users (i.e. non-programmers who don't know what
"compile" means), but still, compiling source code isn't always an
option.

Most distros do distribute prebuilt binaries, but if your app isn't part
of the distribution, things get tough. You have to set up your own
RPM/deb repository and have complicated instructions for people to set
things up so that the right version is downloaded, etc.. Not very
friendly to end-users who want things to Just Work.


> Windows apps tend to just work.

Generally true.

Though when they fail, they tend to fail in rather horrible ways. I
remember long frustrating nights of trying to make two apps that require
conflicting DLLs install properly without trampling all over each other
and deleting system files that crash the entire system. And this was on
my wife's laptop with a relatively small number of programs installed,
and which is only used for limited things like email, browsing, etc.. I
can only imagine the horror it in large, non-trivial installations.

But then again, I *did* also have to deal with having to repair a remote
Linux server whose dynamic linker broke, causing basic commands like ls,
cp, chmod, to be completely non-functional. In fact, *nothing* worked
except that last remote login running bash. In the end I had to use
bash's built-in echo command to recreate a statically-linked busybox
binary via copy-n-pasting over the terminal, in order to get things back
into working condition again. (Yeah. Definitely not for the faint of
heart.)

So I couldn't tell you which is worse. :) At least on Linux you actually
have a fighting chance of fixing the problem, whereas on Windows you
most probably have to just reformat and reinstall the entire system.


T

-- 
Acid falls with the rain; with love comes the pain.


More information about the Digitalmars-d mailing list