This is the kind of screw you get with backwards compatibility

http://msmvps.com/blogs/jon_skeet/archive/2012/03/16/diagnosing-weird-problems-a-stack-overflow-case-study.aspx

tl;dr - Windows fakes you out, basically giving you different files at the 
same place in the file system depending on whether you're running a 32-bit 
executable or a 64-bit executable, because people hard-code the path to 
Windows binaries into their code and expect it to still work.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> because people hard-code the path to 
> Windows binaries into their code and expect it to still work.

  Who's more at fault here? Stupid programmers, or Windows? (Did Windows
always offer an abstract way of getting paths to system directories?)

-- 
                                                          - Warp

Post a reply to this message

On 3/16/2012 23:36, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> because people hard-code the path to
>> Windows binaries into their code and expect it to still work.
>
>    Who's more at fault here? Stupid programmers, or Windows? (Did Windows
> always offer an abstract way of getting paths to system directories?)

The stupid programmers. Windows has for many many years offered ways of 
getting at the system directories without hard-coding them. (I don't know 
about Win3.1, but certainly after that. Certainly since the time of NT3, 
since you could install both in the same partition.)

It's still screwy because it adds more and more complexity to a system to 
program around the bugs of other people. :-) Having to read blog posts to 
find out why the file you're opening with one program isn't the same file 
you're opening with the same name in another program is just screwy.

It would be nice if one could check for such bugs and warn or crash or not 
compile the program at all, before it got released.  Too late for that, tho. 
Sadly not the sort of thing people tend to think about in the early versions 
of a platform where it's needed the most. Maybe as new platforms come out 
(like cell phones, etc) people will learn from history and actually put in 
checks that you're not violating the rules. Sadly, having no formal 
specification makes this sort of thing very difficult.

We had the same sort of screwiness at Google before they replaced "make". 
See, with Make, you don't actually have to declare all the dependencies of 
your program. You can include a .h file that you don't list in the makefile, 
for example. Which led to problems when someone changed a shared .h file and 
your code didn't get tested or recompiled. So now the build system checks 
that. I don't remember whether they watch what files the compiler opens, or 
whether they only copy into the compile environment the files you 
transitively depend on, but if you don't include in your project build 
config file some .h or .jar or whatever that you actually depend on, your 
code won't even compile. (Which is a bit annoying, because your IDE will 
like it, but it won't compile, or vice versa.)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> We had the same sort of screwiness at Google before they replaced "make". 
> See, with Make, you don't actually have to declare all the dependencies of 
> your program.

  make was not designed to keep track of dependencies automatically
(I suppose because make was originally language-agnostic), but there
are other similar tools that do.

-- 
                                                          - Warp

Post a reply to this message

On 3/17/2012 10:48, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> We had the same sort of screwiness at Google before they replaced "make".
>> See, with Make, you don't actually have to declare all the dependencies of
>> your program.
>
>    make was not designed to keep track of dependencies automatically
> (I suppose because make was originally language-agnostic), but there
> are other similar tools that do.

I know that. We don't keep track automatically of the dependencies either. 
But we check that what you declared to be the case is right. Sort of like 
strong typing vs weak typing. :-) Made easier by the fact that you declare 
your dependencies on packages rather than individual files. I say "I use the 
XML processor and the logging package", not individual files that make up 
those packages.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 3/16/2012 9:45 PM, Darren New wrote:
> This is the kind of screw you get with backwards compatibility
>
>
http://msmvps.com/blogs/jon_skeet/archive/2012/03/16/diagnosing-weird-problems-a-stack-overflow-case-study.aspx
>
>
> tl;dr - Windows fakes you out, basically giving you different files at
> the same place in the file system depending on whether you're running a
> 32-bit executable or a 64-bit executable, because people hard-code the
> path to Windows binaries into their code and expect it to still work.
>
Snort, I have seen this sort of thing happen with ones that "do" sort 
of, ask the OS where things are, like they are supposed to. I moved a 
program's data directory a while back and found that it had *literally* 
done this, in the process of installing:

1. Install components.
2. Ask the OS where the user's profile was located.
3. Hard-code this into a location in the registry.
4. Assume it will never change.

This wouldn't have been a problem except.. it had a program function to 
"consolidate installed extensions to a single place", so you didn't have 
all of them scattered all over the place, when downloading them, then 
installing them, and when it tried to do this it suddenly discovered 
that the "consolidation" directory didn't exist any more, but was too 
stupid to ask the OS if the thing had been moved.

To me, it seemed like a simple question of, "Why the hell did you bother 
asking the OS in the first place, instead of letting the user pick a 
location, if you are going to ignore what the OS knows about it *after*?"

Post a reply to this message