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

Warp wrote:
> The source code has to
> know the endianess of the target system in order to be able to write
> bytes in the proper order.

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

I'm not sure how these two jibe. Either you're processing the muti-byte 
objects in native order and writing them in a different order, or you're 
writing them without processing them. In either of those cases, I don't 
see compiler-generated code being slower than programmer-generated code.

The only way I can see it being slower is there's actually two different 
sets of code, based on what order things are in, such that (for example) 
one branch adds two numbers using "+" and the other does some magic to 
add 0xA000 and 0xA000 to get 0x4001 automatically without actually 
treating them as binary integers. Is that what you're referring to?

-- 
   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:
>   Which one did they use, specifically?

I don't remember. I think it was the GNU one, but it might have been BSD.

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

Jim Henderson wrote:
> Our software testers used the trick you 
> describe to make programs work together that had this type of conflict.

I wouldn't call it a *trick* as such. It's a part of the design in the 
OS to support exactly the situation you had. :-)

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