View mode: basic / threaded / horizontal-split · Log in · Help
February 21, 2012
Re: Questions about windows support
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.)

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.

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.



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.).


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.

Windows apps tend to just work.
February 21, 2012
Re: Questions about windows support
On Mon, Feb 20, 2012 at 06:38:47PM -0600, Andrei Alexandrescu wrote:
> On 2/20/12 6:25 PM, Adam D. Ruppe wrote:
> >On Tuesday, 21 February 2012 at 00:19:47 UTC, Jonathan M Davis wrote:
> >>In my experience, you only run into weird terminal nonsense
> >>with old computers or maybe sometimes with ssh. Other than
> >>that, there aren't any weird problems like that.
> >
> >It happens a lot if you use a lot of different unixes.
> >ssh from Linux into BSD, for example, and it is easy
> >to hit these incompatibilities.
> 
> ssh into Windows and... well last time I did it it was like "welcome
> to Hell".
[...]

Heh, I didn't know you could ssh into Windows.

Now I know never to actually do it. :-)


T

-- 
"Life is all a great joke, but only the brave ever get the point." -- Kenneth Rexroth
February 21, 2012
Re: Questions about windows support
On Mon, Feb 20, 2012 at 06:44:16PM -0600, Andrei Alexandrescu wrote:
> On 2/20/12 6:41 PM, Adam D. Ruppe wrote:
> >On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
> >>ssh into Windows and... well last time I did it it was like "welcome
> >>to Hell".
> >
> >Oh, certainly!
> 
> Rats. I was hoping the boys in Redmond have improved the situ since.
[...]

Why would they, though? AFAICT the entire Windows system was designed to
be centered on the GUI. I'm sure they would recommend using some kind of
remote desktop instead of ssh for remote administration. It would fit
better into the Windows way of doing things, and avoid a lot of the pain
that comes when you try to *not* do things according to Windows' way.

(Yes I was stupid enough to try that before. Never dared try it again.)


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are
perfectly safe; if you look at it the thousandth time, you are in
frightful danger of seeing it for the first time. -- G. K. Chesterton
February 21, 2012
Re: Questions about windows support
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.
February 21, 2012
Re: Questions about windows support
On 21 February 2012 15:06, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>
> 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.

As a former Gentoo user, emerge is not user friendly (but neither is
the OS in general), I get your point however.

Arch Linux does well with the Arch Build System. pacman (the package
manager) just installs the software the way the package tells it to,
it has built-in support for remote repositories, but you can also just
install local packages. This means that a system like the Arch User
Repository works, since not everything in the official repos is
update, and not everything is even /in/ the repos, I can normally go
to the AUR, download a PKGBUILD archive, extract it, use makepkg to
download+build it, then use pacman to install it. Not the simplest
workflow in the world, but there are utilities like yaourt to make it
easier (basically pacman for AUR).

--
James Miller
February 21, 2012
Re: Questions about windows support
On 02/20/2012 11:06 PM, H. S. Teoh wrote:
> On Tue, Feb 21, 2012 at 02:00:20AM +0100, Adam D. Ruppe wrote:
> ...
> 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? :-)
> ...

I can think of one case where the command line argument limit
is a problem: copying or moving files from a huge directory.
 In that case, to do it with bash, there is no other way around
but to do things such as iterate over the alphabet to copy the files that
start with 'a', then the ones with 'b'..


> ...
> 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.)
> ...
> 
> T
> 

That is so COOL!! I remember f*cking up one of my first linux computers
that way. If I had known, I wouldn't have to go back to reinstall the
many diskettes of slackware (no live cds at that time!, no easy way
to fix the fs).

--jm
February 21, 2012
Re: Questions about windows support
On Tuesday, 21 February 2012 at 02:05:16 UTC, H. S. Teoh wrote:
> Same with Linux, I thought? Although I mainly just use vim for
> programming, so maybe I'm unaware of the full situation.

Yup.

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

They don't help that much, since they can't hide the underlying
reality.

Consider how you highlight some text in there. You'd have
to do a change attributes, then a move, then a draw, then
move back.

ncurses has functions and macros to make it a little simpler,
but not that much. (especially if your termcap is broken...)

Mouse is a pain too. ncurses sometimes helps but what about
gpm?

Even old, fairly reliable programs have trouble with mouse. I
do most my programming in vim, inside gnu screen, displayed in
an xterm.

Sometimes, it works great. Sometimes, though, if I click too far
to the side.... it sends some bizarre sequence that vim interprets
as a drag then input.

The ugly escape sequences showed through to the end user (me)!



Another bad one is when I open mysql on a remote server in my
beloved rxvt, hit hte home key, and.... well, it is actually 
working
for me today. But, I've many, many times had it say ^[~m or 
something
like that.

Ugh.



Oh yeah, another one. Ever try to make an app in ncurses where you
hold in a button? I believe it was shift+page up that I wanted,
and its impossible because the terminal it is emulating didn't 
have
a sequence for shift pressed, shift released, nor shift+page up.

You could do that if you were talking to the hardware... but linux
emulates some ancient pieces of trash, so you're left out.


Oh oh, one more. Ever try to run a colored app in a different 
color
terminal?

vi with syntax highlighting fails easily. In vim, you can do
:set bg=light. My vimrc has an environment variable I set 
(ELVISBG)
for my various things.

But... run it in screen. Start it in a white xterm. Detach and
reattach to a black putty.

The contrast is all wrong.



There's no way for an app to query the colors in a unix terminal!


Some ncurses apps just redraw the whole thing. Some use 
environment
variables or something.


But, there's no way without you telling it, and if things change,
it is easy to get out of whack.



Speaking of out of whack, ever resize a terminal connected to a
remote session and see it not work? You're typing a long command,
and it suddenly wraps back well before the edge and overwrites
your old stuff.


My god.



Here's another one: have someone set a prompt with a wrong escape
sequence. bash will mess up the length and will draw over your 
other
stuff as you backspace.





I've been using linux every day for about seven years now. I can
go on all day!



The windows one isn't perfect, not by any means, but it has
a nice separation of control, input, and output.

The Windows console api separates these things. You have an output
buffer and an input event loop, with key and mouse events. You
can set attributes on the cells (very much like the hardware 
again :) )
and get updates and query the system separately from the I/O 
channel.

Much better design. If it did selecting by lines by itself and had
nicer resizing, it'd be a real winner.


> But I agree with you though, that libc incompatibilities are 
> really really REALLY annoying.

Even worse is linux's binary incompatibilities.

The dmd in the zip doesn't work out of the box on centos
for instance... have to recompile it.

> 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.

D rox.

> That's more a bash limitation than anything, AFAIK.

Yes and no. bash (and the kernel) is good about it now,
but it is an effect of the unix design of the shell
doing the expansion.

rm *

could have sent argv == ["rm", "*"], and your app
simply done foreach(a; glob(argv[1..$])) { delete(a); }
or whatever.

But, unix decided to do this in the shell. Which isn't
all bad, it has some nice effects.

But, run that in a folder with 20,000 items, and you send
20,000 strings in argv...



Another side effect of this is

rename *.html *.htm

doesn't just work, since it is all expanded there. You have
to make sure the wildcards are all at the tail of the
command, so you have

rename .htm .html *.htm

instead. Not bad, and an easy rule to get used to, but kinda
annoying at times.

> Besides, what *were* you
> trying to do with such a long command-line anyway? :-)


Once company I worked for had an old FreeBSD system
that dumped tens of thousands of files in a few locations...
which tended to fill up the disk.

They had a cronjob to delete stuff every so often, but it
grew big enough that the cron failed because there was too
much to delete.

And then the disk filled up and it was piles of fun. You'd
be amazed at how many unix apps refuse to run if they can't
write to /tmp!


> Most distros do distribute prebuilt binaries, but if your app 
> isn't part of the distribution, things get tough.

Aye, or if the version you need isn't in there. centos,
I'm looking at you!


> But then again, I *did* also have to deal with having to repair 
> a remote Linux server whose dynamic linker broke

I've had that one too.... I had the luxury of being able
to put in a cd though. Mount the drive and copy that stuff
back to it.
February 21, 2012
Re: Questions about windows support
On Tuesday, 21 February 2012 at 02:56:13 UTC, Juan Manuel Cabo 
wrote:
> many diskettes of slackware (no live cds at that time!, no easy

I love Slackware.
February 21, 2012
Re: Questions about windows support
> That is so COOL!! I remember f*cking up one of my first linux computers
> that way. If I had known, I wouldn't have to go back to reinstall the
> many diskettes of slackware (no live cds at that time!, no easy way
> to fix the fs).

What happened was (If I remember correctly) that I renamed the /lib directory.
(PLEASE DON'T TRY THAT AT HOME!!)

Again, this:

>> 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,

is so cool!!

--jm


On 02/20/2012 11:56 PM, Juan Manuel Cabo wrote:
> On 02/20/2012 11:06 PM, H. S. Teoh wrote:
>> On Tue, Feb 21, 2012 at 02:00:20AM +0100, Adam D. Ruppe wrote:
>> ...
>> 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? :-)
>> ...
> 
> I can think of one case where the command line argument limit
> is a problem: copying or moving files from a huge directory.
>   In that case, to do it with bash, there is no other way around
> but to do things such as iterate over the alphabet to copy the files that
> start with 'a', then the ones with 'b'..
> 
> 
>> ...
>> 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.)
>> ...
>>
>> T
>>
> 
> That is so COOL!! I remember f*cking up one of my first linux computers
> that way. If I had known, I wouldn't have to go back to reinstall the
> many diskettes of slackware (no live cds at that time!, no easy way
> to fix the fs).
> 
> --jm
>
February 21, 2012
Re: Questions about windows support
On 20.02.2012 22:36, Benjamin Thaut wrote:
> 2) Will dmd support exporting/importing data symbols from dlls? I know
> there is a patch that does the data symbol address patching from the
> runtime but thats a feature that should be supported by the compiler
> directly in my eyes.

Importing data symbols works just fine both in DMD and GDC. At least it 
did a couple of years ago. Can't remember if I've tried exporting, but I 
wouldn't be surprised if it worked.

You don't need to do anything special to get it working, just use 
declare the data as 'export extern extern (C)' in your D code.  For D2 
prefix that with '__gshared'.  Not very elegent, but it does work.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home