1) Hey! Don't use common sense with me. It won't work.:-) Back in the day, we didn't NEED common sense!
Seriously, you make an excellent point, namely that assemblers (no matter how capable) are generally tied to a particular platform or CPU family.
2) These days, PnP hardware actually seems to work most of the time, so it admittedly isn't the source of frustration that it once was.
3) Try getting *any* GUI to run in some environments.:-) I will agree that text-mode "frameworks" are perhaps limited in terms of portability, but I would suggest that those limits exist for much the same reason that GUIs are not always particularly portable.
In short: I know, but I wanted to see what kind of response I could generate.:-) Thanks for a good one.
(1) Yeah, I did. That's an important part, too, but it isn't only important for ASM/MASM programmers. A fair number of problems happen in other languages because of a lack of familiarity on the part of those writing the code. See: Buffer Overflows.
(2) I agree. While I would have argued for jumpers and such in the early days of PnP hardware, I'm not sure I would (seriously) today. I'm just playing Devil's Advocate on this one, but don't tell anyone...;-)
(3) GUIs are pretty, no doubt about that, and for a number of things (say, creating flowcharts or something) a GUI is probably the best bet. So why do I find myself doing so much text processing in a fullscreen console these days?:-)
(1) with assembly language and a good macro-assembler, one can actually write fairly programmer-friendly code,
(2) non-PNP cards are often a lot easier to support when something goes wrong during hardware resource allocation (at least with IRQ and address jumpers you KNOW where the device thinks it should be), and
(3) text-mode is more portable than a GUI while still being easy to use if a good text-mode UI is also present (remember that drop-down menus and mouse support are not the exclusive domain of bitmapped environments).
My copy of OS/2 Warp 4 running at home on my 192MB PPro/200 box is capable of doing most of what you cite, and yet it seems at least as fast as my 512MB 2.4GHz P4 box at work running Windows XP. Both multitask, both run Firefox well, both play or rip MP3s in the background, and both can work with graphics. The OS/2 box is actually capable of running in higher res given my work monitor's limitations.
I could use resizable and rotatable vector fonts, create and import both bitmap and vector graphics, and load both a spellchecker and thesaurus in my copy of GeoWrite that ran under GeoWorks Ensemble 2.1 and MS-DOS 3.3 in 1991.
Not only that, but the program was well-designed enough to provide four different levels of UI complexity (allowing new users to use it without getting lost while expert users could enable all the features and even customize the toolbars), and the PC/GEOS environment itself provided multiple threads per process and preemptive multitasking but was fast enough to be considered "fast" on my 286 with 1MB of RAM and a VGA card.
The PC/GEOS folks got around the bloat because they were interested in doing so, and they were successful in almost all respects.
Modern coders seem a lot less interested in doing so, perhaps because so many of them take the bloat for granted. It wasn't always so, as many of us remember...
Early versions worked fine, later versions used a sound library that broke sound support in an OS/2 VDM.
I remember an e-mail conversation with ID Software about it, and one of the guys was a real prick, but American McGee was pretty cool about it (while also saying that it was really a DOS game after all and support under OS/2 wasn't a priority).
Thankfully, Doom Legacy works just fine in a VDM.:-)
...though I remember it being a real irritant once.
It isn't a very common occurrence these days, at least on my box, and I've had pretty good luck using either top or watchcat to blow things away when a program decides to go astray.
I agree that a real kill -9 equivalent would be a good thing, though. When it's needed.
...and apparently quite dead in the eyes of the alternative OS community (which pushes Linux for reasons I completely understand, but which still seems to push BeOS for reasons I frankly don't comprehend at all), its perceived death is not a good reason to allow blatant misinformation to be posted on Slashdot, at least without rebuttal.:-)
Besides, OS/2 is still perfectly capable of running modern applications as long as they aren't heavily into multimedia.
I still use Warp 4 as my main desktop OS at home, for example, and it's still humming along on my SCSI-based 192MB PPro/200 box. It runs Firefox, Visio, Quicken, Embellish, and a pile of other programs as well as any other platform could.
I dunno about the IBM mainframe world, but in the Unisys mainframe world, the "home position" is in the upper left. All screen character positioning is done based on 0,0 being home, and a programmer tends to count down for lines and to the right for columns.
"Funny how you fail to mention Windows NT, which was superior to OS/2 in every way execept the graphical shell."
Since you mention the graphical shell, I'll assume you're talking about OS/2 2.0 or later with the WPS and not earlier 1.x incarnations.
What about the fact that OS/2 came bundled with Rexx while NT had nothing at all similar?
That OS/2's MVDM was significantly better than NT's VDM at running DOS programs?
That OS/2's GUI could be decoupled and replaced with a smaller shell (TSHELL or similar) for use on older hardware for small servers?
That OS/2 consistently beat NT in various performance tests over the years, and even did a cleanup when a single-CPU Warp Server box was put up against a 4-CPU NT Server box on file and print sharing benchmarks sponsored by PC Week?
While NT and its successors certainly have definite advantages, mainly due to market position, I think you vastly overstate its relative position in terms of technology.
Later versions of OS/2 from Warp 3 Connect on had a decent networking stack based on BSD, and most of the 16-bit portions of the kernel are gone at this point in time, so those limitations are no longer current.
The CALL macro language I use here uses a nice mix, I think.
Equivalence is either = or EQ (the latter is used with string variables to force a case insensitive comparison), assignment is:=, and block statements follow syntax like the this:
LOOP WHILE xxxx DO
blah
blah ENDLOOP;
(Could also be "LOOP UNTIL xxx DO", or "LOOP FOR xxxx:= 1 to something DO", or just "LOOP DO", and the ENDLOOP can also have a WHEN clause attached).
CASEENTRY xxxx OF
CASE xxx:
statements
CASE yyy:
statements
CASE *:
default if present ENDCASE;
Most interesting is the way it does IF blocks:
IF something THEN
blah ELSE IF something else THEN
blah blah ENDIF;ENDIF;
Many of them are on non-mainstream platforms like the one I've been making a living on for the past 15+ years (the Unisys Clearpath IX mainframe line, also known at various times as the Unisys 2200-series, the Sperry 11000-series, and the UNIVAC 1108/1110 and friends).
I'd be curious to know where languages like PLUS (aka PLSS, the language used to write much of OS2200) would fall, as well as languages like CALL (an interpreted macro language developed at Unisys Roseville and used to write utilities) and SymStream (also known as SSG, the language used to control large system software compiles and other things). Even transaction-automation languages like TTS might be of interest.
On the Unisys A-series/MCP side of the mainframe world, the WFL command language surely deserves mention, and the "assembler" on that architecture is actually a variant of Algol I believe.
On the Macintosh, a number of folks used to use a nice little interpreted language called Hypercard, which allowed one to create a series of graphical panels with images and buttons and link them together graphically, and I remember some fairly powerful interfaces written in that languages under MacOS 7 and 8.
Many of those languages are still in use, but bear little resemblance to the somewhat mainstream languages that are shown on those trees...
People seem to like writing flight planning systems in Fortran, and we had several other major systems written in Fortran when I worked for an airline. Even the "modern" Unix-based system that replaced one of the mainframe systems while I was there had Fortran 66 code at its core.
Airlines were one of the first areas of industry to use computing heavily and are still using many older specialized applications, so that might explain the continued use of (and development in) that language.
In the mainframe transaction environment I write Fortran code for, it's still true.
While it isn't a good thing from some people's perspective, think about it this way: memory leaks induced by application programmers become nonexistent, and a machine with virtual memory is doing to dynamically page the process in and out at the OS's whim anyway so the fixed sizes seen by the applications programmer in that environment don't really matter all that much.
Each module I create is limited to roughly 262K words of memory. It may or may not use it, and it really doesn't matter to me. All I have to care about is getting the thing to compile!:-)
> Mind-bendingly stupid global variable mechanism (COMMON blocks)
We don't use those. It's easier to map common areas to a memory file and INCLUDE a PROC with relevant DEFINE names.
> Back in the day, identifier names were limited of something like six characters. Tens of > thousands of lines of code later, it's anybody's guess as to what a given variable or function does.
Here's a new term for you: "naming convention":-)
Where I used to work, the convention commonly followed was this:
* External refererences (usually defines for fields in a file) were six characters, with the first two indicating the subapplication code, the third being the file, and the last four being used for the field itself.
* Local references were usually five characters, but loop counters could be one-character.
It wasn't all that hard to learn that anything that was WXSxxx belonged to the Weather Station Record, WXGxxx to the Weather Grid record, etc., and LOOOP was a local loop counter.
Some defines (e.g., WXGLEN or WXGVER) are actually quite obvious (the WX Grid Record record length and version number respectively).
> I feel terrible for you folks who had to deal with this horrible language back in the day.
I feel terrible for you folks who have to type in 40-character mixed-case variable names when we are able to save both time and typos.:-)
Slashdot Mirror
H-A-T-R-E-D is one of the best breakup songs of all time. IMO. :-)
Music for people who think Warren Zevon is too light and cuddly
Geeks listen to rap?
:-)
Since when??
Bach, Zeppelin, Oasis, Meat Puppets, Tonio K, or even Abba, maybe... But at least that's music.
The two are not mutually exclusive, and I suspect most Linux users who also use Wine have a valid Windows 95, 98, etc., license around somewhere.
The EULA says I must have a Windows license, but it doesn't say I must use that licensed copy of Windows to run the software.
Strangely enough, that was the last release of the Win32s.dll series, at least as far as I know...
1) Hey! Don't use common sense with me. It won't work. :-) Back in the day, we didn't NEED common sense!
:-) I will agree that text-mode "frameworks" are perhaps limited in terms of portability, but I would suggest that those limits exist for much the same reason that GUIs are not always particularly portable.
:-) Thanks for a good one.
Seriously, you make an excellent point, namely that assemblers (no matter how capable) are generally tied to a particular platform or CPU family.
2) These days, PnP hardware actually seems to work most of the time, so it admittedly isn't the source of frustration that it once was.
3) Try getting *any* GUI to run in some environments.
In short: I know, but I wanted to see what kind of response I could generate.
(1) Yeah, I did. That's an important part, too, but it isn't only important for ASM/MASM programmers. A fair number of problems happen in other languages because of a lack of familiarity on the part of those writing the code. See: Buffer Overflows.
;-)
:-)
(2) I agree. While I would have argued for jumpers and such in the early days of PnP hardware, I'm not sure I would (seriously) today. I'm just playing Devil's Advocate on this one, but don't tell anyone...
(3) GUIs are pretty, no doubt about that, and for a number of things (say, creating flowcharts or something) a GUI is probably the best bet. So why do I find myself doing so much text processing in a fullscreen console these days?
(1) with assembly language and a good macro-assembler, one can actually write fairly programmer-friendly code,
(2) non-PNP cards are often a lot easier to support when something goes wrong during hardware resource allocation (at least with IRQ and address jumpers you KNOW where the device thinks it should be), and
(3) text-mode is more portable than a GUI while still being easy to use if a good text-mode UI is also present (remember that drop-down menus and mouse support are not the exclusive domain of bitmapped environments).
My copy of OS/2 Warp 4 running at home on my 192MB PPro/200 box is capable of doing most of what you cite, and yet it seems at least as fast as my 512MB 2.4GHz P4 box at work running Windows XP. Both multitask, both run Firefox well, both play or rip MP3s in the background, and both can work with graphics. The OS/2 box is actually capable of running in higher res given my work monitor's limitations.
So where is the productivity gain, exactly...?
My fingers got transposed there and I didn't catch it...
I could use resizable and rotatable vector fonts, create and import both bitmap and vector graphics, and load both a spellchecker and thesaurus in my copy of GeoWrite that ran under GeoWorks Ensemble 2.1 and MS-DOS 3.3 in 1991.
Not only that, but the program was well-designed enough to provide four different levels of UI complexity (allowing new users to use it without getting lost while expert users could enable all the features and even customize the toolbars), and the PC/GEOS environment itself provided multiple threads per process and preemptive multitasking but was fast enough to be considered "fast" on my 286 with 1MB of RAM and a VGA card.
The PC/GEOS folks got around the bloat because they were interested in doing so, and they were successful in almost all respects.
Modern coders seem a lot less interested in doing so, perhaps because so many of them take the bloat for granted. It wasn't always so, as many of us remember...
I think it has been expanded in the latest kernels, yes. Not sure, though, since the only thing I've seen it impact is WIN32S 1.30.
That would be useful for DOS games if one isn't using an ISA sound card under OS/2.
Early versions worked fine, later versions used a sound library that broke sound support in an OS/2 VDM.
:-)
I remember an e-mail conversation with ID Software about it, and one of the guys was a real prick, but American McGee was pretty cool about it (while also saying that it was really a DOS game after all and support under OS/2 wasn't a priority).
Thankfully, Doom Legacy works just fine in a VDM.
"It also ran windows apps much better than windows did."
Yes, it did, at least until Microsoft "innovated" and started the Win32s.dll release-of-the-month club.
It's a lot harder to support a non-native API which is in a state of constant flux.
...though I remember it being a real irritant once.
It isn't a very common occurrence these days, at least on my box, and I've had pretty good luck using either top or watchcat to blow things away when a program decides to go astray.
I agree that a real kill -9 equivalent would be a good thing, though. When it's needed.
...and apparently quite dead in the eyes of the alternative OS community (which pushes Linux for reasons I completely understand, but which still seems to push BeOS for reasons I frankly don't comprehend at all), its perceived death is not a good reason to allow blatant misinformation to be posted on Slashdot, at least without rebuttal. :-)
Besides, OS/2 is still perfectly capable of running modern applications as long as they aren't heavily into multimedia.
I still use Warp 4 as my main desktop OS at home, for example, and it's still humming along on my SCSI-based 192MB PPro/200 box. It runs Firefox, Visio, Quicken, Embellish, and a pile of other programs as well as any other platform could.
What isn't "current" about it besides mindshare?
I've used OS/2 since right after the 2.0 release and I still use my Warp 4 box for most things, but I didn't really see a point to joining a fan club.
:-)
It's more fun to be an independent fan.
FWIW, I'm quite a fan of Linux and BeOS as well; I just don't use those platforms as much.
That's what I used as my secondary machine for a while. Very nice, and jet black before that color became such a trendy thing. :-)
I dunno about the IBM mainframe world, but in the Unisys mainframe world, the "home position" is in the upper left. All screen character positioning is done based on 0,0 being home, and a programmer tends to count down for lines and to the right for columns.
"Funny how you fail to mention Windows NT, which was superior to OS/2 in every way execept the graphical shell."
Since you mention the graphical shell, I'll assume you're talking about OS/2 2.0 or later with the WPS and not earlier 1.x incarnations.
What about the fact that OS/2 came bundled with Rexx while NT had nothing at all similar?
That OS/2's MVDM was significantly better than NT's VDM at running DOS programs?
That OS/2's GUI could be decoupled and replaced with a smaller shell (TSHELL or similar) for use on older hardware for small servers?
That OS/2 consistently beat NT in various performance tests over the years, and even did a cleanup when a single-CPU Warp Server box was put up against a 4-CPU NT Server box on file and print sharing benchmarks sponsored by PC Week?
While NT and its successors certainly have definite advantages, mainly due to market position, I think you vastly overstate its relative position in terms of technology.
Later versions of OS/2 from Warp 3 Connect on had a decent networking stack based on BSD, and most of the 16-bit portions of the kernel are gone at this point in time, so those limitations are no longer current.
The CALL macro language I use here uses a nice mix, I think.
:=, and block statements follow syntax like the this:
:= 1 to something DO", or just "LOOP DO", and the ENDLOOP can also have a WHEN clause attached).
Equivalence is either = or EQ (the latter is used with string variables to force a case insensitive comparison), assignment is
LOOP WHILE xxxx DO
blah
blah
ENDLOOP;
(Could also be "LOOP UNTIL xxx DO", or "LOOP FOR xxxx
CASEENTRY xxxx OF
CASE xxx:
statements
CASE yyy:
statements
CASE *:
default if present
ENDCASE;
Most interesting is the way it does IF blocks:
IF something THEN
blah
ELSE IF something else THEN
blah blah
ENDIF;ENDIF;
Many of them are on non-mainstream platforms like the one I've been making a living on for the past 15+ years (the Unisys Clearpath IX mainframe line, also known at various times as the Unisys 2200-series, the Sperry 11000-series, and the UNIVAC 1108/1110 and friends).
I'd be curious to know where languages like PLUS (aka PLSS, the language used to write much of OS2200) would fall, as well as languages like CALL (an interpreted macro language developed at Unisys Roseville and used to write utilities) and SymStream (also known as SSG, the language used to control large system software compiles and other things). Even transaction-automation languages like TTS might be of interest.
On the Unisys A-series/MCP side of the mainframe world, the WFL command language surely deserves mention, and the "assembler" on that architecture is actually a variant of Algol I believe.
On the Macintosh, a number of folks used to use a nice little interpreted language called Hypercard, which allowed one to create a series of graphical panels with images and buttons and link them together graphically, and I remember some fairly powerful interfaces written in that languages under MacOS 7 and 8.
Many of those languages are still in use, but bear little resemblance to the somewhat mainstream languages that are shown on those trees...
Heh. Real men use @FOR. :-)
People seem to like writing flight planning systems in Fortran, and we had several other major systems written in Fortran when I worked for an airline. Even the "modern" Unix-based system that replaced one of the mainframe systems while I was there had Fortran 66 code at its core.
Airlines were one of the first areas of industry to use computing heavily and are still using many older specialized applications, so that might explain the continued use of (and development in) that language.
> No dynamic allocation
:-)
:-)
:-)
In the mainframe transaction environment I write Fortran code for, it's still true.
While it isn't a good thing from some people's perspective, think about it this way: memory leaks induced by application programmers become nonexistent, and a machine with virtual memory is doing to dynamically page the process in and out at the OS's whim anyway so the fixed sizes seen by the applications programmer in that environment don't really matter all that much.
Each module I create is limited to roughly 262K words of memory. It may or may not use it, and it really doesn't matter to me. All I have to care about is getting the thing to compile!
> Mind-bendingly stupid global variable mechanism (COMMON blocks)
We don't use those. It's easier to map common areas to a memory file and INCLUDE a PROC with relevant DEFINE names.
> Back in the day, identifier names were limited of something like six characters. Tens of
> thousands of lines of code later, it's anybody's guess as to what a given variable or function does.
Here's a new term for you: "naming convention"
Where I used to work, the convention commonly followed was this:
* External refererences (usually defines for fields in a file) were six characters, with the first two indicating the subapplication code, the third being the file, and the last four being used for the field itself.
* Local references were usually five characters, but loop counters could be one-character.
It wasn't all that hard to learn that anything that was WXSxxx belonged to the Weather Station Record, WXGxxx to the Weather Grid record, etc., and LOOOP was a local loop counter.
Some defines (e.g., WXGLEN or WXGVER) are actually quite obvious (the WX Grid Record record length and version number respectively).
> I feel terrible for you folks who had to deal with this horrible language back in the day.
I feel terrible for you folks who have to type in 40-character mixed-case variable names when we are able to save both time and typos.
I'm not sure if there's even an F90 compiler available for this particular environment (basic mode HVTIP/USAS on a Unisys 2200/500).