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

I should mention that 'export' also works for importing.  It does the 
job of both '__declspec(dllimport)' and '__declspec(dllexport)'.
February 21, 2012
Re: Questions about windows support
On Mon, Feb 20, 2012 at 11:56:11PM -0300, 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'..

for x in *; mv $x dest/$x; done


Easy. :)


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

That is only cool in retrospect. I remember sweating bullets at the
time, thinking twice about every command I typed, lest I accidentally
lose that last ssh session into the box. (New ssh connections don't
work, for the same reasons.)

Especially tense was when I used xclip to copy 10000 echo commands into
the paste buffer and then pasted the result into the ssh terminal. You
have no idea what a sigh of relief it was when it was finally done and
the connection was still alive. :-P The slightest slip, like an
accidental EOF at the wrong place in the paste, and it's bye-bye ssh
connection, bye-bye remote server.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes,
you already said that." -- User-Friendly
February 21, 2012
Re: Questions about windows support
On Tuesday, 21 February 2012 at 03:13:10 UTC, H. S. Teoh wrote:
> for x in *; mv $x dest/$x; done
>
> Easy. :)

And wrong!

What if the filename has a space in it? You can
say "$x", with quotes, to handle that.

But, worse yet... a leading dash? Another downside
with the shell expansion is the program can't tell if
that is an expanded filename or a user option.

In this case, the mv simply wouldn't work, but you
can get some bizarre behavior out of that if you
wanted to play with it.

try this some day as a joke:

$ mkdir evil-unix # toy directory
$ cd evil-unix
$ touch -- -l # our lol file
$ touch cool # just to put a file in there
$ ls
-l  cool
$ ls * # the lol file is interpreted as an option!
-rw-r--r-- 1 me users 0 2012-02-20 22:18 cool
$


imagine the poor newb trying to understand that!
February 21, 2012
Re: Questions about windows support
On Tue, Feb 21, 2012 at 12:07:41AM -0300, Juan Manuel Cabo wrote:
> > 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!!)

Haha, ouch. That would suck, real bad.

It could be worse. Some guy somehow messed up his packaging system so
much that when he ran an upgrade command, the packager somehow decided
that it had to uninstall EVERY package on the system (including
essential stuff like /bin and /lib).  Which it proceeded to do, until it
deleted so much of the system that it broke itself and crashed. Leaving
a system without /bin, /lib, or /usr.

It was from this guy's website that I learned how to copy binary files
using echo. :-)


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

I don't know if that's cool, or just plain crazy. You have no idea how
hard it is to actually create an executable using echo commands. What
with bash interpolating the input strings at various places multiple
times, you have to double-escape, triple-escape, even quadruple-escape
some of the hex sequences just to get it to work properly.

For example, I had to represent a *single* binary 0 as \\\\0000,
because I couldn't paste the commands directly at the prompt, since bash
does something with the terminal after every line, so the input buffer
would overflow and start truncating commands about 5-6 lines into the
paste. So I had to use this hack:

	(IFS=$'\n';while read line;do echo "$line";done) > target.script

to copy the pasted command into a script file, and then run that script
afterwards. But the 'echo "$line"' introduced yet another level of
interpolation, so what started out as \0 turned into \\\\0000. You could
clean out your mouth several times over with that amount of toothpicks.
:-P


T

-- 
Frank disagreement binds closer than feigned agreement.
February 21, 2012
Re: Questions about windows support
On Tue, Feb 21, 2012 at 04:00:17AM +0100, Adam D. Ruppe wrote:
> 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.
[...]
> 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)!

I've always been of the opinion that ALL control sequences should be
sent over a separate channel. Mixing controls with data (characters) is
a Bad Idea(tm). But alas, if you were to implement such a terminal,
pretty much *everything* would break, since everyone assumes the
terminal is just a single stream of mixed controls + data.


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

Is that because you're trying to do this through gnu screen? I use
screen all the time too, and I've discovered that it does really strange
things with terminal settings. When I use ssh directly, these problems
go away. Perhaps it's a bug in screen.


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

I'm not a fan of using colored terminals. It's trying to patch new
functionality over an incompatible interface. You're bound to have
problems.


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

Oh? I thought ncurses does.


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

But you're right that most ncurses apps just assume that once they start
running, the colors will stay put. Assumption fails as soon as screen
comes into the picture.

Most *good* ncurses programs will repaint the screen on a keystroke,
like ^L. But yeah, that's a workaround, not a solution.


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

I think you're seeing bugs in screen. I can resize my ssh terminals no
problem, it manages to communicate that fact to the remote end, which
sends a SIGWINCH to the app, which then resizes itself. This works in
putty from Windows too.

But once screen sits in the middle, all bets are off.


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

Heh, never seen that before. I usually just turn off all fancy settings
after installing a new system, and just stick with a bare-bones prompt.


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

Only seven years? ;-) I've been at it for several years longer.


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

Oh? This must be new. The last time I actually programmed anything on
Windows was... oh wait, it was on DOS. :P  The creeping horror that was
Windows 95 was one of the things that prompted me to switch to Linux for
good. But I don't remember console I/O being so nice. They must've
improved it since I last saw it.


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

The fundamental problem with the Unix concept of terminal is that it
wants to treat EVERYTHING as a stream of bytes. Which is a powerful
abstraction, granted, but when it fails, like when escape sequences get
out of sync, it fails in horrible ways. I've always argued that control
and data needs a clean separation.


> >But I agree with you though, that libc incompatibilities are really
> >really REALLY annoying.
> 
> Even worse is linux's binary incompatibilities.

But that can't be helped when you have such proliferation of distros,
OS versions, library versions, etc.. I almost never download binaries,
only source.


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

My favorite effect is this:

	mv filename.{oldext,newext}

which only makes sense if the shell expands it.

OTOH, I quite miss the good ole DOS days with Norton Commander, where
you can type:

	rename *.oldext *.newext

and it would do the right thing.


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

I remember hitting an upper limit on that once, but I don't know if I
remembered correctly.


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

I find it *very* annoying. But still, with all its warts, I find myself
much more productive at the commandline than at a GUI.


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

Ah. Ouch.


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

LOL...


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

Ugh. Don't remind me. At work I use ctags a lot so that I can use vim's
tag function (super useful for navigating large source trees!). Then
recently, some new code was introduced that produced hundreds of
thousands of symbols... and ctags would soak up all RAM, thrash on I/O,
near-freezing the computer, then die at the end when sort runs out of
space in /tmp.

It's both funny and sad at the same time.


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

That's why I love debian backports. :)


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

Provided 'mount' and 'cp' are statically linked, otherwise you're still
screwed.  Of course, if you could boot from CD, then you're OK.

I didn't have the luxury: it was a remote server (hosted at a very
remote location).


T

-- 
Don't throw out the baby with the bathwater. Use your hands...
February 21, 2012
Re: Questions about windows support
On Tuesday, 21 February 2012 at 03:53:20 UTC, H. S. Teoh wrote:
> But alas, if you were to implement such a terminal,
> pretty much *everything* would break, since everyone assumes the
> terminal is just a single stream of mixed controls + data.

Yeah... I've been wanting to do it, but it'd mean
redoing almost every app and that just isn't worth
it.

> Is that because you're trying to do this through gnu screen?

The shift+ certain keys is a limitation of the terminal
itself, not just screen.

Now, screen sometimes does some weird things, but I've
found it does a pretty good job on the whole.

(really annoying is if you start up vim from a box with X.
vim connects to X. Then detach it in screen and reattach
in another window. vim dies with a BadWindow X error when
you make a selection. Ugh.)


Anyway screen works well with what it has. Even if it has
bugs - terminal window titles never seem to be quite right
with it for example - its so well worth it.

screen is one of my favorite programs.

> Oh? I thought ncurses does.

The best I've seen is environment variables, which are
easy to get out of sync.


> Most *good* ncurses programs will repaint the screen on a 
> keystroke,
> like ^L. But yeah, that's a workaround, not a solution.

Yea. And then you lose your custom color anyway, as the
app repaints in its own way.

> Heh, never seen that before. I usually just turn off all fancy 
> settings
> after installing a new system, and just stick with a bare-bones 
> prompt.

I like slackware's default of \u@\h:\w\$

Simple, informative, reliable.


But, one of the sysadmins I worked with fell in love with
colors. I still have access to one of his systems, let
me pull this up... this system is slow! come on...

Here we go:
# echo $PS1
\033[0m\033[36mname\033[34mredacted\033[0m#

Two different colors forming the system's name! And no
useful info. This isn't a prompt. It's a logo.


But, he loved it. And it is kinda cool, just blargh,
especially when the escape sequences get broken up
for whatever reason and the whole thing goes to hell.

(Which is easy to happen - type a long line. bash offers
a special sequence to let it know what you're escaping, but
he didn't use it on this system so bash thinks the prompt
is longer than it is, which breaks the line wrapping.)


> Only seven years? ;-) I've been at it for several years longer.

I'm relatively new but just as grizzled :-)


> Oh? This must be new.

I think Windows NT or maybe 2000 introduced it.

I actually liked working with DOS though. Good old
segment b800 where can just write your bytes and see
them on screen.

Fond memories here of video mode 13h too. That was
easy programming, and good speed too, even on those
old computers.

When I finally switched to coding for these
newfangled multitasking OSes, it took a long time
to get used to not having my precious memory map.


> I've always argued that control
> and data needs a clean separation.

I agree entirely.

> I almost never download binaries, only source.

Me too, which is kinda sad when distributing software.

I like sharing my apps with Windows users because
I can say "grab this exe and have fun".

With Linux users, there's always some list of third
party stuff they need too. dmd, qt, whatever, but
always something.


> My favorite effect is this:
>
> 	mv filename.{oldext,newext}
>
> which only makes sense if the shell expands it.

Nice one!


> much more productive at the commandline than at a GUI.

command lines rock.


Actually, I complain, but my system is a hacked up
blackbox with rxvt and xterm on hotkeys, so I can
summon and dismiss them with ease. (I put them on
the menu key next to the right ctrl key. One press,
rxvt comes. I can order it around, then ctrl+d to
get rid of it. Easy come, easy go.)

It works so well that I barely need anything else.


What pains me most about using windows though? It isn't
the command line.... it is that you can't turn off click
to raise.

You can turn on sloppy focus and it is decently usable.
But, I've never found a way to make it so you can click
a window without it going to the top.

In fact, some Windows windows go to the top whenever they
focus.... which kinda neuters sloppy focus too.

Gah! I love that model. Stacking windows is just no fun
if they always insist on going to the top.


> I didn't have the luxury: it was a remote server (hosted at a 
> very remote location).

That sucks.
February 21, 2012
Re: Questions about windows support
Many only know the UNIX version of Linux or BSD, but lets not forget the
idiosyncrasies any developer faces when having to support multiple 
commercial
UNIX systems in spite of standards like POSIX.

I still remember the first time I loggeded into an HP-UX system in a 
production system
at one of our customers, back in 2000. It was like time travel to the 70's.

The same can be said of Solaris. My first task after setting up a Solaris 
server (v6-8) was
always to go to a repository like Sunfreeware and get a set of sane userland 
tools.

These are just two stories, but I have many to share from our support 
between Windows and
UNIX flavours we had to support (Linux, BSD, Aix, HP-UX, Solaris and Aix).

Sure Windows is sometimes a pain to work with, but commercial UNIXes are not 
far off.

--
Paulo

"Adam D. Ruppe"  wrote in message 
news:cekchlmrcfupiocywkfv@forum.dlang.org...

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
You need to enable it.

"H. S. Teoh"  wrote in message 
news:mailman.748.1329787800.20196.digitalmars-d@puremagic.com...

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
They did, but Microsoft way as usual.

SSH in Windows, means making use of Powershell remote access. SSH is only 
meant
for UNIX compatibility and it works better if SUA (UNIX personality) is also 
installed.

--
Paulo

"Andrei Alexandrescu"  wrote in message 
news:jhupcv$2l7j$1@digitalmars.com...

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.

Andrei
February 21, 2012
Re: Questions about windows support
On 21 February 2012 01:00, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
> > On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
> > > 1) Is there a chance that dmd will support 64 bit on windows any
> > > time soon? What are the issues currently with 64 bit support on
> > > windows?  (optlink? backend?)
> >
> > Neither support 64-bit. So, the changes required to the toolchain are
> > _far_ greater for 64-bit Windows than the Posix OSes. It'll come
> > eventually, but probably not for a while.
> [...]
>
> Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.
>

I use GDC in windows, and it's good. It's always up to date too, which is
nice.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home