From: "Matthias Paul" Organization: Rechenzentrum RWTH Aachen To: opendos AT delorie DOT com Date: Wed, 29 Nov 2000 17:27:36 +0100 Subject: Re: Optimizing CONFIG.SYS... X-mailer: Pegasus Mail v3.22 Message-ID: <8C1FAD261CA@reze-1.rz.rwth-aachen.de> Reply-To: opendos AT delorie DOT com On Wed, 29 Nov 2000 Patrick Moran wrote: > I'll disassemble whatever I want whenever I want, screw them! > [...] > If they can't write decent software and will not > guarantee it, then we have no choice but to do it ourselfs! I generally agree with you, although I think, it depends on what you do exactly. First, disassembling and debugging are not the same thing. In many cases, you can still debug a piece of code while not looking at the instructions e.g. by trapping functions etc. Also, even when you need to see assembler instructions, they hardly reflect the source code (often written in higher languages) of the original work, but you can still get a grasp of what it is doing. And that's all that's needed. Any well-versed developer has no need to *use* foreign proprietary code (it's not only against ethics, but it would for sure be illegal), but you often need to have sharp looks because you're spotting a problem or a not documented case. I postulate, that almost not a single non-trivial and compatible DOS program can be written without using undocumented DOS internals. I really would prefer this would not be the case, but real world is different from an academic point of clean coding. This is why books like "Undocumented DOS", "Undocumented Windows" or "DOS Internals" and projects like Ralf Brown's Interrupt List exist. Furthermore, there are cases, where keeping things undocumented is illegal (when the info is needed by other vendors to develop well-behaving and performant programs in a particular environment - any bells ringing? ;-), or where even reverse-engineering (which is even far beyond of disassembling and debugging I originally spoke about) would be legal (for example when you need it to spot someone elses illegal practices and you do not make the re-engineered stuff public, sometimes even beyond of that, when you use clean-room practices). For example, many of the Y2K bugs in older programs (not only PCs and DOS based) could only be fixed by reverse-engineering existing binaries to source code that could be re-compiled after applying the fixes. A whole (though temporary) industry was built on that. One more example, in early summer 1997 I did in fact reverse- engineered (not just debug) the whole Novell DOS 7 update 15.2 kernel to re-develop sources for the patches for update 11 - 15.2 (that is, everything they changed during year 1995) which have gone lost somewhere at Novell. Fortunately almost all of them (except for the latest BIOS sources, which finally have been found back in 1999 ;-) showed up later, but without that effort, DR-DOS 7.02+ and higher would now be based on Novell DOS 7 update 10 or so. This also was completely legal, because Caldera bought the whole DRI stuff from Novell, not only the original "Novell DOS 7" product. Summarizing I should say that it is far easier to just develop nice looking code, but especially in the DOS environment you need very detailed specifications (including all the special cases and existing or previously fixed bugs, which are never mentioned in the offical documents) to not run into compatibility problems with some DOS issues or under some circumstances. And since many of these details are not documented, there really is no other choice than having sharp looks from time to time. Everybody who seriously programs has to and does. I wish things would be different... Well, there are things that are legal and other's are not. This is, of course, no pledging for anything unlawful. As always, it depends on purpose and intention. Matthias