Prev: Linking issue
Next: compiler/linker flags to abort array assignment (non-standard) useduring run time
From: Kevin G. Rhoads on 23 Apr 2008 10:19
>I don't directly remember decimal floating point arithmetic routines,
>but other things imply they were there.
>However, I know my (shiny new?) MS F77 Fortran complier has such a
>library (decmath.lib), as well as binary floating point and others.

AFAIK MS Fortran 3.3 DECMATH.LIB uses the 80x86 packed BCD math instructions.
ALTMATH is compromise math lib for machines without x87s which runs faster than 87 emulation, but lower precisions.
MATH.LIB is the 87 emulation and 8087.LIB uses the x87 (and dies horribly if not present IIRC).

But harking back to Steve Lionel's original response, not only are the WinXX APIs much
fuller than the INT 21H API of DOS, the library granularity is much poorer these days.
It take effort and thought to properly generate fine granularity libraries. Just like it
too effort to support multiple math library options. Most compiler vendors can't justify
that effort these days because they need to concentrate efforts on other things (such as
chasing the latest API changes from MS or the latest new hardware features from Intel or
AMD, just as a couple of minor examples ;-) or on implementing new language features.

IIRC a simple F77 "hello world" was a few 10s of k with any of the 16 bit MS Fortrans,
but about 1/8 Meg with FPS4, and close to 1/4M with DVF5.

The trouble with DLLs for the runtime is the issue of "DLL Hell". So long as you are
the *only* thing on the system using that runtime DLL, no matter how many programs you
have using it, fine. But as soon as another vendor's proggie uses it, then the possibility
of versionitis arises. ANd "DLL Hell" is nothing but extreme versionitis.

No, I prefer everything statically linked in. And I hate the EXE bloat that results,
but I find that less problematic than the problems of DLLs. But limiting EXE size
by employing DLLs is a viable alternative, if you are willing to put up with the problems
that potentially arise.
From: Craig Powers on 23 Apr 2008 14:33
Kevin G. Rhoads wrote:
>
> The trouble with DLLs for the runtime is the issue of "DLL Hell". So long as you are
> the *only* thing on the system using that runtime DLL, no matter how many programs you
> have using it, fine. But as soon as another vendor's proggie uses it, then the possibility
> of versionitis arises. ANd "DLL Hell" is nothing but extreme versionitis.

DLL Hell is a combination of vendor indiscipline (failure to maintain
backward compatibility in newer versions of stuff) and ill-behaved
developers (who allowed their installations to overwrite newer versions
of files with older versions of files). It needn't have been an issue.
From: Kevin G. Rhoads on 24 Apr 2008 09:09
>DLL Hell is a combination of vendor indiscipline (failure to maintain
>backward compatibility in newer versions of stuff)

Well, given that intentionally poor backward compatibility has been
a marketing strategy for forcing upgrades and grabbing market share
for some decades, (e.g., Intel dissing the 286 once the 386 was
released, after they could (and did) argue that the second source
agreement with AMD was for the 286 only and did not cover the 386;
second example, the continually changing specs for MS Word documents,
NTFS, &c) I would suggest that calling lack of good backward compatibility
"indiscipline" is a rather narrow view of the whole process.

Coercing people to upgrade by providing intentionally incompatible or
poorly backward compatible programs, file formats, hardware &c is a
way of life for the business-geeks and marketing-droids -- for technorati
to ignore this is double-plus ungood (Orwellian reference intentional).

<tongue-in-cheek>
Of course the solution to DLL Hell is *CLEARLY* TPM -- signed drivers --
program certification and trusted sources (Mwuhahahaha). And if you buy that
I have some waterfront property in South FLorida you may also be interested
in. </tongue-in-cheek>

DLL Hell was inevitable for the M$ world. As Linux becomes increasingly
commercialized, it may see the same widespread problem developing.

What makes sense commercially and what makes sense technologically are
often not well aligned. Proper resolution of the oftimes conflicting
drives is highly non-trivial. And the "right" solution is often very
subjective, even in hindsight.

MHOO -- YMMV
From: Paul van Delst on 24 Apr 2008 11:00
Kevin G. Rhoads wrote:

> What makes sense commercially and what makes sense technologically are
> often not well aligned. Proper resolution of the oftimes conflicting
> drives is highly non-trivial. And the "right" solution is often very
> subjective, even in hindsight.

I'm going to print this out as my chosen negget of net-wisdom for this quarter and display
it in my cube entrance. We all are aware of it, but it's nice to see it written out
clearly like you have above.

cheers,

paulv

p.s. Could one substitute "commercially" with "bureaucratically", and thus "often not
well" with "never" ? :o)
From: Dan Nagle on 24 Apr 2008 11:28
Hi,

On 2008-04-24 09:09:34 -0400, "Kevin G. Rhoads" <kgrhoads(a)alum.mit.edu> said:

> <tongue-in-cheek>
> Of course the solution to DLL Hell is *CLEARLY* TPM -- signed drivers --
> program certification and trusted sources (Mwuhahahaha). And if you buy that
> I have some waterfront property in South FLorida you may also be interested
> in. </tongue-in-cheek>

Would your agent be with The Low Tide Land Comapny?
"When you see the land you want-- it's low tide!" ;-)

--
Cheers!

Dan Nagle

 | 
Pages: 1
Prev: Linking issue
Next: compiler/linker flags to abort array assignment (non-standard) useduring run time