Since October 1987 it is maintained by Ralf D. Brown,[23] a researcher at Carnegie Mellon University's Language Technologies Institute
Language as in human languages, not computer languages --- and this is noteworthy because it's illustrative of how many in the PC software/hardware scene were back then; they didn't learn programming and the details of the PC architecture to become specialised career developers, but because they wanted to create software/hardware to serve some other purpose related to their actual work/personal life. Of course there were career developers, but there were also far more "power users" who "graduated" into programming too. For example, I remember interacting with a gardener who learned and wrote an application --- in x86 Asm --- because she wanted to make various calculations regarding the plants she was managing.
Contrast that with these days where many low-level details are heavily guarded, there's plenty of people willing to sell you something close to what you want (and try to convince you that it is exactly what you want), users are strongly divided into "consumers" and "developers" and the former largely discouraged from learning about how things work, and the average career developer is completely clueless about what would traditionally be considered "power user" features, and might even struggle with basic concepts like a command line. The Internet is filled with plenty of information only a search away, but the majority of it isn't good.
I started work in 1992,and joined the generation "computerizing the world". We literally sold computers with our software - most customers had zero, of maybe 1 computer.
I was almost unique in that my qualification was computer science. My boss was a mechanical engineer. His partner was a land surveyor. I would go to a conference and I'd meet doctors, lawyers, mechanics, pilots, police, pretty much every occupation under the sun except "programmer".
All of these folk had the same story, they needed something for their day job, so they learned, and wrote it. Many pivoted into selling the stuff they wrote. I made/make a living selling technology and training to this generation. They often have significant market share in niche markets.
But today its different. Table stakes for entry is two magnitudes larger. I started with a thin apple 2 book, and coded the same day. Our commercial programs (for DOS) were primitive. They've had 30 years to grow. Today out the box you need to understand Windows, databases, integrations, networking and do on. The days of Dr Bob writing some software for his practice are gone. Programming, like doctoring, requires a lot more now to make an impact.
The next generation will have their own path to tread, their own stories to tell. But our path, our experience, is of limited value to them.
I'm an Industrial Designer and in 1992 every office just handed all computer tasks to the young. I learned about networks and planned a Novel 3.11 Network with a Mac NLM for a 30 person office. I then added an Ascend Pipeline 50 to connect an ISDN and added a nice layer or TCP/IP. This was probably the most exciting 5 years of learning. The Macs were all moved to system 7 which had built-n networking the PCs needed the Novel server to centrally share files. and we bought Asante NuBus internal cards for Mac SE/30 and the Mac IIs. We also used Asante SCSI to ethernet adaptors. I transformed from a Macintosh power user to system administrator. I was lucky to have exposure to IBM PCs because I learned the fundamentals and they haven't changed at all last time I looked.
The Macs all hid their interrupts but could handle all the same default number peripherals as an IBM PC.
The IBM PC had all sorts of configuration files. These files included describing the hard drive's mechanical specifics. The network cards all needed a to be assigned an open IRQ.
This was the defining difference between a Macintosh and an IBM PC. The other more obvious difference was the GUI.
I became a Metcalfe Law zealot.
I actually feel we are entering the same sort of frenzy of new development.
Counterpoint: a Raspberry Pi 4 is more open and infinitely better documented than the Apple IIe/II+ computers I learned BASIC on in the early 80’s. There was actually lots of great printed documentation for the Apple II, but you had to actually find it. And it was not easy to find it, and it was expensive to buy it, and you couldn’t buy much of it if you were of limited means.
We are in a golden age for accessible electronics, programming, and computing in general. As a bonus, filesystem are generally reliable; you no longer have to deal with fiddly and unreliable magnetic storage (tapes and floppies). It’s harder to lose work than ever before.
And what passes for a datasheet is, because Broadcom, horribly incomplete (I'm still surprised no one has leaked the full datasheet yet; but thanks to the latter, even MTK-based Android smartphones are more "open and infinitely better documented"...)
There was actually lots of great printed documentation for the Apple II, but you had to actually find it. And it was not easy to find it, and it was expensive to buy it, and you couldn’t buy much of it if you were of limited means.
But you didn't have to sign an NDA for it, nor be big and important enough to even get a chance of being offered an NDA.
For a "more open and infinitely better documented" general-purpose computer, IMHO nothing beats the IBM PC up to the AT, and even after that, PC-compatibles up to perhaps the mid 2000s. Full schematics --- even for the floppy drive, PSU, and monitor(!), CPU datasheets, BIOS source code, etc. Then came RBIL, and the rest is history.
I wonder whether the Raspberry Pi organization now has enough clout to push for more-open hardware at doable price points.
Or maybe some other vendor comes in (possibly with something RISC-V-based, and at least using only open source drivers, if not an open hardware GPU). They could do upstream Debian or a fork of Raspian on it, and to most users operate the same as a RasPi, only more open. (Maybe compatibility problems would be mostly due to people using closed software on a RasPi, perhaps without realizing it.)
It's easy to feel nostalgic for the old days, but what really was better back then?
Really, the only advantage you had back then is that you often had no other choices but to learn to program computers in order to use them. It's much easier to program computers today, and it's much easier to learn to program, but the only problem here is that you're faced with a hundred or a thousand different alternatives for how to learn to program, or how to solve your task in ways that don't involve learning to program.
I like showing off the Apple II to younger programmers. You turn it on and immediately you start writing code. This had the benefit of immediacy, but it was worse in almost every other conceivable way. Basic was horrible and didn't let you do structured programming. It was easy to lose your program. It was hard to make changes and iterate. Easier to start, but much harder to develop mastery.
Which-way still is a problem, even for experienced developers. Do you believe it’s easier to develop mastery now? If old programming was a cellar, modern programming is a dungeon, each corner leading to another dungeon. Losing a program is not a big deal, in contrast to losing or accumulating wrong experience.
Continuing the analogy, we dreamed for our experience to see the light, but that never came true. I think that’s where the nostalgic sentiment comes from.
> the only problem here is that you're faced with a hundred or a thousand different alternatives for how to learn to program.
This is a well studied and absolutely serious issue called decision fatigue [1]. You seem to be downplaying it's consequences by a large margin, most likely because you do not understand it.
The comment was really good right up until the point where you started speculating about whether I understand the point you’re making. You could just delete the second sentence there, and nothing of value would be lost from the otherwise high-quality comment!
I'm nostalgic for the excitement. I don't believe things were better. I think things are about to make a major leap that will turn the past 25 years of development into a blip.
Wow, what a blast from the past. I used this site so much. It was the bible of all things related to interrupts. I recall using this site when writing several TSRs. What fun that was and feeling a great sense of nostalgia.
Back in the day it was fun to create your own text reader application, it really caught on probably after someone in the demo scene did it first, then it became sort of its own little status symbol along with whatever demo effects you were doing.
Honestly I just recall the format of the document and how helpful it was, not how I accessed it. It has been too long (30 years?) for me to recall details like that.
Hah, that brings back a lot of good memories. Also of the cold at the attic where my pc was. Got my copy via floppy disks, of course. It also reminded me of “TechHelp”, if my memory serves me well it could run as ISR and you could summon it with a hot key. Apparently someone has been awesome enough to convert the dos program into a website: http://www.techhelpmanual.com/
Ohh, full on nostalgia. I remember stumbling upon it for the first time, it was a priceless treasure. It seems that someone converted it into NG format [1], because wiki only mentions raw text and diffs. NG was very useful since its reader stayed TSR so you could refer to it without leaving an editor.
You probably meant int into windows syscalls. IRQs are hardware-generated interrupts, when hardware demands attention. And the syscall instruction, as the fast int replacement, is not recognized at all in real or vm86 modes.
In the end, it depends on the environment that you use to run the FreeDOS, whether it forwards them or not. Note that windows does not provide binary compatibility at syscall level, only at ntdll level, which would be useless outside currently running windows, so it could be useless even if it was forwarded.
You just brought me great memories of me and my dad setting up those hand-operated black and white logitech scanners. Having to connect custom ISA cards and manually configuring IRQ ports and DMA channels in the cards. Normally done through jumpers... and when we got a card with Dip Switches!! it was THE FUTURE.
This was gold back in the DOS days. Software interrupts were used as a system call interface, both to DOS but also to various drivers. Getting documentation was tricky; the Interrupt List brought it all together.
That's the kind of info that I loved that was circulated at that time. I remember playing with TSRs and Mode-X. I made some stupid virus-like program and played extensively with graphics as well...
Nowadays, I am sad it is not as easy to play with our hardware such as Mobile phones at the same level. I wish we could at least use C to interact at the hardware level with mobile phones. Shit, it was even possible to do it with the Nintendo DS (via devkitARM)
Depends on the game, it's difficult to draw a perfect circle with non-square pixels. It was possible to achieve 320x240 though, problem was you needed more than 64Kb of memory for that and couldn't get the graphics buffer in a linear memory layout.
Not at all. But I remember dearly my first 3D program (a rotating wireframe dodecahedron) was all stretched out. The screen coordinates had to be scaled by a factor like 6/5 or 5/4 before display.
"almost all" is greatly exaggerating. Mode X was much less used than EGA or VGA 320x200 modes. As a consequence, many games look completely wrong with a standard DOSBox configuration these days (characters are fat!), because it still doesn't use aspect ratio correction by default.
It's not exaggerating; I cannot remember a single VGA title made after '91 that uses plain mode 0x13. Primary reason being not being able to double buffer. By that time, EGA titles were also practically dead, the notable exception being Civlization.
Sure, there were games pre-91, but in the '90, the PC market exploded, together with available games. The amount what was available in '90s dwarfs the older titles, so "almost all" is greatly fitting.
Yeah one great thing about the TP's inline assembler was that you could write the first draft of for example a TSR program in Pascal and then translate it piecemeal into assembly until you could ditch the compiler completely and just use the TASM.
Yup, that was my experience - otherwise you end up paying some kb of runtime attached. - One of my TSR was to transform the 320x200x256 buffer from one game into hercules (640x200) mono (1bit) mode. For the Trolls game - it was super slow, but worked, and it was more enjoyable making the hack, than playing it.
Another cool feature (back then) was this TSR which would let you save the state of the RAM running, and then save again and again, and by doing diffing you can find where certain game would keep life points, etc.
Lol, I did something similar. Not saving the whole RAM, but I made a TSR to first scan memory for an integer, which would create a list of all hits. I could then rescan as soon as the number changed (your character's hp for example), and it would just filter down the list from the first scan. Repeat until you're down to one hit, and you've got your candidate for a write operation! Actually worked on a couple of games... =)
Yup - it was also fun to find that some games were keeping the HP points as text - there was at least one, involving a ninja (but can't remember the name of the game).
Oh, and that tool was someone else that wrote it, not me. But was quite popular in the PC clubs I was going to.
One particular application was for the resident-style apps (like keyboard locale switchers, or process killers of sorts (e.g. kill anything that started after me), etc.). But also INT 21H, and others.
I downloaded this off my mate's BBS back in the olden days, early-to-mid 90s maybe.
I might well have an image of the SIMTEL CD it was on. I remember it being a .zip file a few hundred kB long that took a good ten minutes or so to download on the modem I'd borrowed.
Language as in human languages, not computer languages --- and this is noteworthy because it's illustrative of how many in the PC software/hardware scene were back then; they didn't learn programming and the details of the PC architecture to become specialised career developers, but because they wanted to create software/hardware to serve some other purpose related to their actual work/personal life. Of course there were career developers, but there were also far more "power users" who "graduated" into programming too. For example, I remember interacting with a gardener who learned and wrote an application --- in x86 Asm --- because she wanted to make various calculations regarding the plants she was managing.
Contrast that with these days where many low-level details are heavily guarded, there's plenty of people willing to sell you something close to what you want (and try to convince you that it is exactly what you want), users are strongly divided into "consumers" and "developers" and the former largely discouraged from learning about how things work, and the average career developer is completely clueless about what would traditionally be considered "power user" features, and might even struggle with basic concepts like a command line. The Internet is filled with plenty of information only a search away, but the majority of it isn't good.