5 ms·

"To get the most performance out of the PCs of the day, I believe he had the register itself more or less directly read and write transaction data from disk."

by enneff 16y ago

"To get the most performance out of the PCs of the day, I believe he had the register itself more or less directly read and write transaction data from disk." I don't buy this excuse. It just sounds like bad code to me.

jerf 16y ago
Times were different back then. The article says the original control dates from 1990, and wikipedia confirms that Windows 3.0 came out in 1990 so it is plausible. The 486 had just been released in the previous year, so it was the New Hotness and not very many people had it, so you'd be looking at an install base of mostly 80386s with a substantial contingent of 80286s that your program still needed to run on with acceptable performance. Wikipedia says for the 80286 you're looking at a top-end of 12MHz, with 6 and 8 MHz in the field. Since this is a Windows 3.0 program, you had a minimum of 640KB on the system (though of course you can't use it all). So this is a program that has to run with reasonable performance on a 12MHz 80286 with 2MB of RAM. Are you sure you wouldn't consider having your UI read and write the disk directly? Separation of concerns is a modern luxury. And remember, you're using compilers from 1990, too. Don't expect great inlining. (Besides, only profligate memory spendthrifts would inline a function.) (Edit, later followup: In fact, "separation of concerns" is one of the major sources of the "bloat" people complain about when they examine modern OSes. Much of the "non-bloated-ness" of earlier generations of OS doesn't come from programmers caring more about their craft, it comes from programmers having to stuff programs into things that can barely hold them and building "clever things" that we would today consider monstrosities like UI widgets that read and write directly to the disk. I am unsympathetic to accusations that, say, a modern KDE desktop is "bloated".)
- caf 16y ago
  It was a rare 286 indeed that came with 2MB of RAM!
  - jerf 16y ago
    Yes, I was being a bit generous and assuming that perhaps Microsoft Money didn't have to run on the absolute minimum spec for Windows 3.0. I couldn't find the exact specs Microsoft gave for the original version. Considering that I can chew through 2MB in my programs nowadays if I accidentally sneeze wrong it still makes the point, I think. :)
- prodigal_erik 16y ago
  To be fair, memory bandwidth was relatively better and pipelines were nonexistent, so there was little reason to inline a function unless the call setup was literally longer than the body. My favorite monstrosity was the http://en.wikipedia.org/wiki/Overlay_(programming) http://en.wikipedia.org/wiki/Overlay_(programming). When your OS couldn't page functions from disk for you, you damn well did it yourself. They even started building it into linkers....
  - m_eiman 16y ago
    The madness still exists today. I'm developing an app that runs on a 8-bit 8051 CPU with a 16 bit address bus and 1MB of code Flash... Let's just say that segmentation and function pointers isn't a perfect match. Luckily the next revision of the hardware runs an AVR32 instead, I'm just hoping that the hardware will be ready for the world before the app is!
- demallien 16y ago
  In fact, "separation of concerns" is one of the major sources of the "bloat" people complain about when they examine modern OSes. Um, what is your source for that assertion? From where I'm standing, separation of concerns is a technique which favorises the re-use of code, and hence the reduction of bloat.
  - jerf 16y ago
    Separation of concerns at the OS level involves the creation of shared DLLs, and people complaining about bloat inevitably complain about the many megabytes of DLL files that the simplest program needs nowadays, even if it only uses a vanishing fraction of them. People slinging bloat accusations around seem to want a program in which every byte loaded from the disk is executed with high frequency or something. In my opinion, you're totally correct. This is part of the reason I'm not very sympathetic to the bloat argument. The megabytes of libraries are there for good reasons.
- enneff 16y ago
  "So this is a program that has to run with reasonable performance on a 12MHz 80286 with 2MB of RAM. Are you sure you wouldn't consider having your UI read and write the disk directly?" I wrote code for those machines, and no, I wouldn't write my UI code to read and write the disk directly. "Separation of concerns is a modern luxury." This is a myth. Merely an excuse for poor API design. Proper abstraction doesn't mean inefficiency. Your last paragraph (the "Edit") is almost offensive. The cause of bloat is not separation of concerns. It's that people just don't care about writing efficient code (or they just don't know how). Did you ever write code in the era you speak of? Because your statement comes across as ill-informed conjecture.

by enneff 16y ago

jerf 16y ago

Times were different back then. The article says the original control dates from 1990, and wikipedia confirms that Windows 3.0 came out in 1990 so it is plausible. The 486 had just been released in the previous year, so it was the New Hotness and not very many people had it, so you'd be looking at an install base of mostly 80386s with a substantial contingent of 80286s that your program still needed to run on with acceptable performance. Wikipedia says for the 80286 you're looking at a top-end of 12MHz, with 6 and 8 MHz in the field. Since this is a Windows 3.0 program, you had a minimum of 640KB on the system (though of course you can't use it all). So this is a program that has to run with reasonable performance on a 12MHz 80286 with 2MB of RAM. Are you sure you wouldn't consider having your UI read and write the disk directly? Separation of concerns is a modern luxury. And remember, you're using compilers from 1990, too. Don't expect great inlining. (Besides, only profligate memory spendthrifts would inline a function.) (Edit, later followup: In fact, "separation of concerns" is one of the major sources of the "bloat" people complain about when they examine modern OSes. Much of the "non-bloated-ness" of earlier generations of OS doesn't come from programmers caring more about their craft, it comes from programmers having to stuff programs into things that can barely hold them and building "clever things" that we would today consider monstrosities like UI widgets that read and write directly to the disk. I am unsympathetic to accusations that, say, a modern KDE desktop is "bloated".)

caf 16y ago
It was a rare 286 indeed that came with 2MB of RAM!
- jerf 16y ago
  Yes, I was being a bit generous and assuming that perhaps Microsoft Money didn't have to run on the absolute minimum spec for Windows 3.0. I couldn't find the exact specs Microsoft gave for the original version. Considering that I can chew through 2MB in my programs nowadays if I accidentally sneeze wrong it still makes the point, I think. :)
prodigal_erik 16y ago
To be fair, memory bandwidth was relatively better and pipelines were nonexistent, so there was little reason to inline a function unless the call setup was literally longer than the body. My favorite monstrosity was the http://en.wikipedia.org/wiki/Overlay_(programming) http://en.wikipedia.org/wiki/Overlay_(programming). When your OS couldn't page functions from disk for you, you damn well did it yourself. They even started building it into linkers....
- m_eiman 16y ago
  The madness still exists today. I'm developing an app that runs on a 8-bit 8051 CPU with a 16 bit address bus and 1MB of code Flash... Let's just say that segmentation and function pointers isn't a perfect match. Luckily the next revision of the hardware runs an AVR32 instead, I'm just hoping that the hardware will be ready for the world before the app is!
demallien 16y ago
In fact, "separation of concerns" is one of the major sources of the "bloat" people complain about when they examine modern OSes. Um, what is your source for that assertion? From where I'm standing, separation of concerns is a technique which favorises the re-use of code, and hence the reduction of bloat.
- jerf 16y ago
  Separation of concerns at the OS level involves the creation of shared DLLs, and people complaining about bloat inevitably complain about the many megabytes of DLL files that the simplest program needs nowadays, even if it only uses a vanishing fraction of them. People slinging bloat accusations around seem to want a program in which every byte loaded from the disk is executed with high frequency or something. In my opinion, you're totally correct. This is part of the reason I'm not very sympathetic to the bloat argument. The megabytes of libraries are there for good reasons.
enneff 16y ago
"So this is a program that has to run with reasonable performance on a 12MHz 80286 with 2MB of RAM. Are you sure you wouldn't consider having your UI read and write the disk directly?" I wrote code for those machines, and no, I wouldn't write my UI code to read and write the disk directly. "Separation of concerns is a modern luxury." This is a myth. Merely an excuse for poor API design. Proper abstraction doesn't mean inefficiency. Your last paragraph (the "Edit") is almost offensive. The cause of bloat is not separation of concerns. It's that people just don't care about writing efficient code (or they just don't know how). Did you ever write code in the era you speak of? Because your statement comes across as ill-informed conjecture.