Post #290,393
8/6/07 5:56:24 PM
|
Logistics query re known 'bad' OS components -
Query on What You Do - when you realize that a defective element in an OS has many clones, one less-broken than other builds - relating to your (browser ap, in this case.)
Let's say you are the rather ept crew of boffins at Moz.
Your Insta-feedback (crash triggered) has apprised you of the fact that, in Beastware versions: a particular .dll has been popping up (er, crashing down.)
Say too, that it is 'msvcrt.dll' -- and all know about Beastware Hell (especially in 9.x versions, as before the Beast knew anything or cared anything about their special Hell thing. Dunno how effective is any registry in eXtra Pain, of course.)
You inspect the sucker; also note that there are indeed Several builds across the years. (I'm sure that I read, sometime back, that there was a particularly less-defective build uncovered - but to get that specific one, you needed to d/l some 20+ MB bugfix involving a peripheral ap to VB. IIRC.)
Clearly a certain amount of disassembly of a few of these versions occurred (else how settle upon one model as Less-broken that others?) Can also appreciate that this crap takes time - and always are there: Priorities.
Point: SeaMonkey also has crashed, but only a couple times since 1.0: as compared with previous Suite, where the crash rate had also declined to ehh, never-mind levels over successive builds. [Always crashes here were re msvcrt, across years. Maybe one or three which were not == not bloody bad at all, IME.]
So then: if some Hero (or fool?) ran amok, disassembled several of these .dll versions and found the bad logic in "most?" of them - would the programmer generate a filter == add more code to SeaMonkey: that detects the version and self-modifies accordingly? (Would this not also slow things, each time that display dll gets called? Decent tradeoff, perhaps, but more chances for incompatibilities elsewhere?)
Just wondering how programmer minds deal with stuff involving (eventually known) OS screwups: where a particular build is determined Good, but there are several Baddish - and they cannot simply send you the \ufffd Good one == the obvious Simple Solution, in a sane world.
YPB
|
Post #290,410
8/6/07 8:49:04 PM
|
programming is the art of linking crap libraries
except for a few around here that understand how it truly works.
thanx,
bill
Quantum materiae materietur marmota monax si marmota monax materiam possit materiari?
Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free american and do not reflect the opinions of any person or company that I have had professional relations with in the past 51 years. meep
reach me at [link|mailto:bill.oxley@cox.net|mailto:bill.oxley@cox.net]
|
Post #290,415
8/6/07 10:22:51 PM
|
So then -
they build the Alpha this way. Test, mostly it works - etc. Beta gets most of the Oops omissions.
I guess you mean, then - there is no investigation of Bad-things in the OS until it's clear that the reported faults are not from Bad-things in the ap, and reprts are continuing. And.. disassembling libraries is a last resort, likely beyond the ken of most of the ap-builders :-/
{sigh} Sounds so Murican-of-late.
Gracias.
|
Post #290,423
8/6/07 10:51:49 PM
|
It's more of an art than a science.
After a while, you get people who know so much about a situation that when they leave, the code is frozen because no-one else knows quite how it works. And then you realize that perhaps only about 5-10% of all programmers ever are actually capable of programming in their head -- as opposed to the majority who merely reuse and recycle techniques they know work and don't have the imagination to see learning opportunities when they arise. Most programming is achieved with the latter type of programmer, not surprisingly. They simply don't have the talent to spot algorithmic errors before they become problems, and thus spend a lot of time doing a) band-aid fixes afterward and b) extending for trivial variants.
Wade, who still remembers when years ago a fellow programmer saw an array of structs that also had pointers to functions - two concepts in C he'd never known existed.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
|
-- "Anything but Ordinary" by Avril Lavigne. | · my ·
· [link|http://staticsan.livejournal.com/|blog] ·
· [link|http://yceran.org/|website] · |
|
Post #290,440
8/7/07 9:36:28 AM
|
Re: Logistics query re known 'bad' OS components -
So then: if some Hero (or fool?) ran amok, disassembled several of these .dll versions and found the bad logic in "most?" of them - would the programmer generate a filter == add more code to SeaMonkey: that detects the version and self-modifies accordingly? (Would this not also slow things, each time that display dll gets called? Decent tradeoff, perhaps, but more chances for incompatibilities elsewhere?) I don't know about Mozilla but in my experience there are two popular ways of dealing with this in code. Some applications use a fall back system, where they try method A and if that fails they switch to using method B and so on. This works well can you can detect failures of an interface, but for many of the nasty problem you either can't or by the time you can it is too late. The second is to determine which versions of key DLLs are installed and modify behavior accordingly when the program starts. This works well when you know exactly which DLLs have which problems, but in reality it is often hard to tell. Most custom built business applications use neither. They just are designed against a specific version of the DLL and if that turns into a problem later it is forced onto the machine as part of the install process. If that can't be done they simply stick with the old version until they have no choice but fix the problem. The company I'm working for now was running Windows NT on some desktops till this year because a key application wouldn't work on XP. Jay
|
Post #290,466
8/7/07 6:46:24 PM
|
Ahh - thanks.
Tradeoffs understood (..so long as that ap isn't running with another ap which wants a different version.) {sob}
So then (were Doze smarter designed) one might envision:
every executable having a descriptive filename plus its version-determined [unique subname] by which it is IDed in memory. You'd have to get around dupe filenames in directories (or as in the olden days - keep those Only in the ap's launch directory?) but there would be no name confusion, on launch. Ah But - then there's keeping the PATH up-to-date and never Too-long :-/
Jeez Billy, you narcissistic amateur. Not 'The Smartest Guys in the Room', though new hires are told that, I've oft heard. (I realize that *nix can load whatever new/old versions of libs - available simultaneously, as needed. Smart college guys.)
One can only wonder how the moz folk (have, apparently and gradually) solved this particular version roulette which I've watched for some years..
Dear esteemed Mozilla programmer, YPB: HTF did you Do this?
|
Post #290,467
8/7/07 7:08:18 PM
8/7/07 8:21:46 PM
|
Side by side on my piano keyboard oh lord why don't we...
Windows XP and later have something called Side-by-Side Assemblies:
Starting with Windows XP, multiple versions of side-by-side assemblies can be used by applications running at the same time. Manifests, and the assembly version number, are used by the loader to determine the correct binding of assembly versions to applications.
...
When an application calls to load the DLL, the side-by-side manager determines whether the application has a version dependence described in a manifest. If there is no relevant manifest, the system loads the default version of the assembly.
-- [link|http://msdn2.microsoft.com/en-us/library/aa376307.aspx|http://msdn2.microso...ary/aa376307.aspx] --
Chris Altmann
Edited by altmann
Aug. 7, 2007, 08:21:46 PM EDT
|
Post #290,472
8/7/07 7:50:43 PM
|
Interesting. Of course, being Microsoft, they break it...
[link|http://et.cairene.net/2006/05/03/behavior-change-in-server-2003-sidebyside/|Behavior change in Server 2003 SideBySide?].
DLLs did make some sense in saving memory and load times on slow, memory-constrained machines. But once MS's APIs got ungodly complex, they tied applications into the OS, etc., etc., then it was guaranteed to break. This [link|http://www.geek-central.gen.nz/peeves/shared_libs_harmful.html|rant] from 1998 makes the point pretty well.
Like many of these things, it seems to be [link|http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=5708811.PN.&OS=PN/5708811&RS=PN/5708811|IBM's fault]...
Cheers,
Scott.
|
Post #290,497
8/8/07 11:49:47 AM
|
Different goal
DLLs where designed for the era when disk space and memory where very limited. The idea was you only ever needed one foo.dll on a system and would ever only load one foo.dll into memory. If another application called foo.dll, Windows just passed a reference to the already loaded copy.
At the time it was a sensible solution, though poorly implemented. Microsoft made two key mistakes from the start, failing to clearly separate system and application DLLs, and not providing a good way of uniquely naming or providing version numbers for DLLs.
What makes it so typical of Microsoft is that they where copying something from Unix, and managed to mess it up. Shared Libraries under Unix are not what I would call elegant. But the system does work and covers all of the major issues.
Jay
|
