Warp wrote:
>   Portability is a key feature of unix-like systems.

I always have to cringe a bit when someone decides that two different 
versions of source code in one file means it's "portable".

#ifdef isn't a sign of portability. It's a sign of lack of portability. 
If your 32-bit code breaks on a 64-bit machine, your language isn't 
portable.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   (Sure, the code could have been written so that endianess doesn't matter,
> but then it wouldn't have been so efficient.)

And of course, in *portable* languages for doing system-level 
programming, you simply specify that particular variables have a certain 
endianness, and you let the compiler write the code to do the 
byteswapping at the places it's needed. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Phil Cook wrote:
> But wasn't it v7 that introduced the ability to layout and print 
> multiple images? Such a handy little thing.

Actually, it's rather annoying.  And v8 tried to improve it and just 
made it way more suckful.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Tue, 11 Mar 2008 11:41:02 -0700, Darren New wrote:

> Jim Henderson wrote:
>> You've been lucky.  Last company I worked for had many applications
>> with DLLs in common but requiring different versions.
> 
> FWIW, that's actually easy to fix. You just put the right version of the
> DLL next to each executable, and create a file in the same directory
> with a magic name (that I disremember offhand but something like
> "loadseparate"), and the DLL loader will look at the directory with the
> executable first for any DLL.  It's the same thing that the
> "side-by-side" is supposed to solve, so googling for that would probably
> lead you to the right place.

Yep, that's what we ended up doing.  The problem is that most software, 
when installed using the installation routines, will install any DLLs to 
the system directory (at least that was the experience at the time, maybe 
it's gotten better by now).  Our software testers used the trick you 
describe to make programs work together that had this type of conflict.

Jim

Post a reply to this message

On Tue, 11 Mar 2008 11:39:07 -0700, Darren New wrote:

> Jim Henderson wrote:
>> And you need to look up again the definition of "DLL Hell".
> 
> You know, they solved this problem quite some time ago... Like, around
> 2000 or earlier.

Took 'em long enough. ;-)

That is about the last time I had anything serious to do with Windows.

Jim

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> ad-hoc *mess* of haphazardly interacting command switches that you 
>> have to spend 20 minutes studying the manpage to decode the 
>> interactions for?
> 
> Don't forget that it also changes behavior depending on whether it 
> things stdout is a terminal, a different character device, or a file.

I presume you mean "don't forget" as in "if you forget this, it's likely 
that your scripting will malfunction horribly"...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I'm 
> not really sure why it's even limited, given I've got 16 gig of real 
> memory and twice that of virtual memory. :-)

  Well, it is an open-source OS after all. There ought to be some magic
constant in the source code of your favorite shell which limits the amount
of command-line parameters. Just increase it an recompile... :P

  (Why isn't it dynamic? Probably because it's written in C, and C sucks.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   (Sure, the code could have been written so that endianess doesn't matter,
> > but then it wouldn't have been so efficient.)

> And of course, in *portable* languages for doing system-level 
> programming, you simply specify that particular variables have a certain 
> endianness, and you let the compiler write the code to do the 
> byteswapping at the places it's needed. :-)

  Which would be slower than writing the bytes in the proper order in
the first place...

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I saw a study done a number of years ago where researchers took each 
> UNIX tool and

  I'm not sure there's such a thing as a "UNIX tool". There are specific
implementations of several established command-line tools (many of which
are standardized by POSIX, plus others). GNU is one example of such
implementation.

  Which one did they use, specifically?

-- 
                                                          - Warp

Post a reply to this message

Eero Ahonen wrote:
> Darren New wrote:
>> Now, if Linux supported the thing that NTFS supports where you can 
>> delete the beginning of a file, maybe I'd use that. But as it is, I 
>> have to chop the file up so I can delete parts of it.
>>
> 
> Could "split" possibly help you?

I already have millions of files. That's the problem. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message