1 Dec
2006
1 Dec
'06
11:35 a.m.
One of the programs available sometime in the late 1980's was a program called
Sourcer that included a program called BIOS Pre-procesor for the PC, a ROM BIOS
Listing generator (V Communications.) Neat program and while I am not a
programmer, it was fun to disassemble the ROM BIOS routines and take a look. The
BIOS listing had enough comments to make it useful.
From: Richard <legalize at xmission.com>
Has anyone considered decompilation (producing sources from binaries)
as a way of archiving system or application software that is defunct?
I know lots of people have disassembled ROM listings and created
commented ASM listings from the ROM, but what about larger systems
where hand-disassembly is impractical?
1 Dec
1 Dec
12:26 p.m.
In article <457059E4.6B05CE66 at rain.org>,
Marvin Johnston <marvin at rain.org> writes:
One of the programs available sometime in the late
1980's was a
program called Sourcer [...]
Its still around and can work on Windows code now. There are a
variety of such programs and this is what got me thinking about such a
beast for vintage computers. Cases where the application source (or
OS source!) has been lost.
Someone asked me in private email why I'd want to do this -- I
consider the source code just as an important historical artifact as
the compiled binaries and physical hardware. For the same reason that
people want schematics for vintage hardware, having source code for
vintage software is also useful.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
2 Dec
2 Dec
10:27 a.m.
On Dec 1, 2006, at 12:26 PM, Richard wrote:
Someone asked me in private email why I'd want to
do this -- I
consider the source code just as an important historical artifact as
the compiled binaries and physical hardware. For the same reason that
people want schematics for vintage hardware, having source code for
vintage software is also useful.
Not only useful, but highly educational. A lot of this sort of
stuff was written back in the days when writing software actually
took some *skills*. Now any kid with a Windows box can slap together
an application in a few hours.
Sure, it'll eat hundreds of megabytes of RAM, be slower than
pissing tar, and probably crash a lot, but then that seems to
describe some of the world's most widely deployed software, so who's
counting?
Back in the early days of computing, some of the *smartest people
on the planet* worked on this stuff. Now, though, every drooling
moron who thinks he can make more money writing Windows apps than
flipping burgers can pirate a copy of Microsoft's Visual Whatever-it-
is-this-week garbage and is suddenly a "programmer".
-Dave
--
Dave McGuire
Cape Coral, FL
11 a.m.
In article <EDC5D417-CCD1-4870-833D-E3822E3AE144 at neurotica.com>,
Dave McGuire <mcguire at neurotica.com> writes:
Back in the early days of computing, some of the
*smartest people
on the planet* worked on this stuff. Now, though, every drooling
moron who thinks he can make more money writing Windows apps than
flipping burgers can pirate a copy of Microsoft's Visual Whatever-it-
is-this-week garbage and is suddenly a "programmer".
The most recent iteration of their development environment is
permanently free :-). So there's no need to pirate Microsoft's Visual
Whatever-it-is-this-week.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
6:16 p.m.
On Dec 1, 2006, at 12:26 PM, Richard wrote:
I would argue software sources are more educational than useful (not that
education is not a very important 'use' :-)). I like scheamtics of old
computers for 2 reasons, firstly to learn how they worked, and secondly
to be able to repair them if something failes. Only the first is really
applicable to software, software doesn't fail in the same sense that
hardware can.
FWIW, even though I don't consdier myself to be a programmer, I do like
reading source listings, the lower the level the better. I have
certainly read through a fair number of microcode sources in my time...
-tony
Someone asked me in private email why I'd
want to do this -- I
consider the source code just as an important historical artifact as
the compiled binaries and physical hardware. For the same reason that
people want schematics for vintage hardware, having source code for
vintage software is also useful.
Not only useful, but highly educational. A lot of this sort of 
8:59 p.m.
On 2 Dec 2006 at 23:16, Tony Duell wrote:
I would argue software sources are more educational
than useful (not that
education is not a very important 'use' :-)). I like scheamtics of old
computers for 2 reasons, firstly to learn how they worked, and secondly
to be able to repair them if something failes. Only the first is really
applicable to software, software doesn't fail in the same sense that
hardware can.
If you're reading someone else's software, the stuff that isn't
executable code can really give you a window on the mind of the
author and answer the question "What kind of person wrote this--a
hack, someone trying to show off, or someone who really put a lot of
thought into what s/he was doing?". And even more importantly, "Did
whoever wrote this actually know what s/he was doing?"
Unfortuantely, you don't get that with decompiled/disassembled code.
It might be possible to infer it, but it's quite a bit more
difficult.
Cheers,
Chuck
3 Dec
3 Dec
1:39 p.m.
In article <m1Gqe60-000Iz0C at p850ug1>,
ard at p850ug1.demon.co.uk (Tony Duell) writes:
[...] I like scheamtics of old
computers for 2 reasons, firstly to learn how they worked, and secondly
to be able to repair them if something failes. Only the first is really
applicable to software, software doesn't fail in the same sense that
hardware can.
It fails in the same sense that a hardware design bug would be sitting
there permanently annoying you until you fixed it. Machines tend not
to ship with hardware bugs because they typically aren't useful with
hardware bugs. They do however ship with lots of software bugs, even
on older machines.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7:08 p.m.
In article <m1Gqe60-000Iz0C at p850ug1>,
ard at p850ug1.demon.co.uk (Tony Duell) writes:
True. That's why I said 'in the same sense'. It's quite possible for
hardware to have worked perfectly for 20 years, and then to stop working
(and not work agian until it's repaired) because some component has
failed. I think it's very unlikely for software to work fine for 20
years, then crash and not run again because of some latent design bug
(unless said software makes use of the real time/date, of course ;-))
-tony
[...] I like scheamtics of old
computers for 2 reasons, firstly to learn how they worked, and secondly
to be able to repair them if something failes. Only the first is really
applicable to software, software doesn't fail in the same sense that
hardware can.
It fails in the same sense that a hardware design bug would be sitting
there permanently annoying you until you fixed it. Machines tend not
to ship with hardware bugs because they typically aren't useful with
hardware bugs. They do however ship with lots of software bugs, even
on older machines. 
5 Dec
5 Dec
2:11 p.m.
Tony Duell wrote:
True. That's why I said 'in the same
sense'. It's quite possible for
hardware to have worked perfectly for 20 years, and then to stop working
(and not work agian until it's repaired) because some component has
failed. I think it's very unlikely for software to work fine for 20
years, then crash and not run again because of some latent design bug
(unless said software makes use of the real time/date, of course ;-))
I have a machine that ran Linux for years, but suddenly
started to hang at random times for no known reason.
Windows 98 ran fine, only Linux had a problem.
I replaced the hard drive, installed a new version of Linux,
and things improved for a month. Then it started hanging
during boot. Windows 98 still ran fine.
I am now replacing several capaciters on the motherboard,
with obvious buldges on the top, and Linux again runs fine.
I still have 4 more caps to go, but need to find ones with
the correct form factor (tight fit). Pulled those I used off
another motherboard that had lightning damage.
I don't know why Windows would run, but Linux would not,
except that Linux makes more use of the motherboard features
than windows would.
I have had experience with one software bug that went
unoticed for years. Then one programmer noticed the bug.
Almost immediately, the software failed because of this evry
bug on numerous systems, where it had run for years.
Eerie.
4 Dec
4 Dec
8:22 p.m.
Tony Duell wrote:
On Dec 1, 2006,
at 12:26 PM, Richard wrote:
I would argue software sources are more educational than useful (not that
education is not a very important 'use' :-)). I like scheamtics of old
computers for 2 reasons, firstly to learn how they worked, and secondly
to be able to repair them if something failes. Only the first is really
applicable to software, software doesn't fail in the same sense that
hardware can.
Someone asked me in private email why I'd want
to do this -- I
consider the source code just as an important historical artifact as
the compiled binaries and physical hardware. For the same reason that
people want schematics for vintage hardware, having source code for
vintage software is also useful.
Not only useful, but highly educational. A lot of this sort of
10:08 p.m.
In article <4574C9F0.2020202 at compsys.to>,
"Jerome H. Fine" <jhfinedp3k at compsys.to> writes:
So software can also fail in ways that are similar to
hardware
problems - EXCEPT that software will NEVER develop an entirely
new bug called a failure due to age problems whereas hardware
will always eventually reach this stage if used long enough.
If this latter characteristic is what you refer to as the prime
difference between hardware and software, then I agree 100%!!!
You mean Bit Rot is a myth? :-)
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
10:41 p.m.
On 4 Dec 2006 at 20:08, Jerome Fine wrote:
So software can also fail in ways that are similar to
hardware
problems - EXCEPT that software will NEVER develop an entirely
new bug called a failure due to age problems whereas hardware
will always eventually reach this stage if used long enough.
If this latter characteristic is what you refer to as the prime
difference between hardware and software, then I agree 100%!!!
But that doesn't imply that time's not an enemy of software!
Obsolescence is the biggest enemy--try making a single MS-DOS 2,1 C:
partition on that new 250GB drive.
In the 70's and early 80's, it wasn't unsual to find programs that
don't deal with dates after 1999. A program may have worked well for
more than 20 years suddenly becomes useless when the century changes.
Old programs using program loops to introduce a small delay. On an
XT, the following loop takes more than a second to execute:
MOV CX, 0FFFFh
Here:
LOOP Here
Cheers,
Chuck
5 Dec
5 Dec
4:08 p.m.
So software can also fail in ways that are similar to
hardware
problems - EXCEPT that software will NEVER develop an entirely
new bug called a failure due to age problems whereas hardware
will always eventually reach this stage if used long enough.
If this latter characteristic is what you refer to as the prime
difference between hardware and software, then I agree 100%!!!
That's exactly what I mean. Software problems are essentially design
errors, hardware problems can be design errors or because some component
has failed.
-tony
6405
days inactive
6409
days old
12 comments
7 participants
participants (7)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
jhfinedp3k＠compsys.to -
kth＠srv.net -
legalize＠xmission.com -
marvin＠rain.org -
mcguire＠neurotica.com