Maybe we need an infrastructure for this. An infrastructure that would be common among multiple languages. And then you could run any language that can target this common language infrastructure. And if you manage it properly it could be secure....
See, that's sharp isn't it? Of course, it might seem like I'm parroting a bunch of buzzwords in this monologue, but I really have a message... I'm not just making small talk. I think that's enough pearls of wisdom in one post.
Oops, I see you said "decryptor." Of course, if you have that, then you've unlocked this key. But, how many keys does the virus have on its keyring and how quickly does it acquire more? It's not like it's a DVD, fixed in a medium or a CSS descrambler ASIC in a $20 DVD player.
RSA is asymmetric encryption. That's why the key-length is so long. It doesn't matter if you have the encryption key. You can't decrypt with the encryption key. Keeping the RAM hot is only helpful for trying to find the plaintext in a disk buffer somewhere.
RSA has much longer key lengths than symmetric encryption due to how the math works out: Only a small fraction of 1024-bit numbers make suitable keys. Encryption / decryption key pairs have very specific mathematical properties related to primes. (See the Wikipedia page the GP posted.)
It wasn't a microprocessor limitation in 1987 ("6 years later"--after the 1981 starting point). It was a PC architecture limitation and real-mode OS limitation. The 80286 came out in 1982 and could address 16MB directly. 80386 came out in 1985, offering 32-bit protected mode and VM86 mode.
Had PC's OS embraced these new CPUs' features more quickly and in a more integrated fashion, we might've avoided years of LIM-EMS, XMS, EMM386 and all the DOS Extenders. (GO32... DJGPP... How I do not yearn for thee.) We never got to have a protected-mode DOS, and Microsoft abandoned XENIX. OS/2 never caught on for some reason, probably because people didn't move from DOS immediately, and Windows provided a bridge, however shaky.
But I'm with you. He did make something of a classic mistake: He made an extrapolation that seems more linear than exponential, or at the very least had too small an exponent. But, he also had a time horizon. He was planning for 10 years, and 640K seemed like enough for that horizon.
First an OT "Howdy!": I think we've crossed paths before on LJ. (lj user=mr_z) Howdy.:-) BTW, where'd you go to school at? It appears we're from the same neck of the woods. Oh, and I turn 33 in a couple months myself.
Swinging back on to the subtopic: Probably one of the larger motivators for Segment + Offset addressing was so that pointers (or, at least the live portion manipulated during loops) could fit in a single 16-bit register. The 8086 was a 16 bit machine, and there was significant advantage to building small applications in a "near" model, and slightly larger applications that rarely dealt with objects larger than 64K.
The 8086 was architected to allow porting 8080 code to 8086 with a minimal translation. This is likely why the 16 bit registers are also addressable as 8-bit H/L pairs. The 8080 H/L registers themselves correspond to the 8086's BX, which explains addressing flexibility heaped on to BX. (As you may recall, the 8080 ganged these two 8 bit registers up to make a 16 bit indirect pointer register.) You might get a larf reading through that XLT86.ASM I linked above--it appears to have been translated by itself! (How's THAT for a test case?)
The segment-offset model also allowed for fixed offsets to be compiled in for "large aggregates" when coding for one of the "large data" models. Large aggregates are things like large arrays and large structs in C. This mode of course requires 32-bit pointers (which are really just seg:ofs pointers, so they only give you a 20-bit address space). This may've been what your professor was thinking of.
I know I've abused the various segmentation models before. I've even used the CS register as an extra data segment in loops that needed to address three separate tables that weren't in the same segment before.:-)
As for SPARC, it just uses a nice, linear, flat 32-bit address space for each task. 32-bit registers make it easy. Even UNIX works that way on 32-bit x86 machines generally. Pointers do, in a sense, get "hard coded," or at least fixed to specific virtual addresses, at final link time. Final link can be at program load time for dynamically-linked binaries, or before that for statically linked binaries.
The A000:0000 thing is weird, of course, because at the time, the CGA and MDA mapped their memory at B800:0000 and B000:0000, respectively. (Don't confuse CGA with MCGA, which is seems to just be a VGA missing its left nut.) EGA and VGA were a ways off when 640K got settled on. Granted, IBM had reserved A000:0000 on up for peripherals, but it wasn't until EGA came along that an IBM video card used A000:0000 for a frame buffer.
A common trick for memory managers to break the 640K memory barrier was to map real memory into holes in the "reserved" area, and link those into the MS-DOS "memory arena." This worked by setting the top of arena to a higher address, and marking the regions occupied by devices as used. Since many programs needed large contiguous allocations, the next step often was to use said memory manager to load device drivers and other small things into these newly available holes, freeing up more of the larger "below 640K zone." You could teach later versions of DOS to put its disk buffers in this "upper memory area," aka UMA. (Not to be confused with the HMA. Ask the guy over there frothing at the mouth about "fast A20 gate" about that.)
All this brings back old memories. Anyone remember this?
A:\> debug
-gc800:5
Mmmm... 615 cylinders, 4 heads, 17 sectors. Lemme bust out OpTune and tweak the interleave. What? 5:1?!?!
That comment about stricmp is interesting. I assume it's bridging the difference between strcasecmp and stricmp. strcasecmp has been around for quite a long time and predates Linux. It's part of SuS.
(The reference above is the oldest I could find with a quick Google search.)
For a packet filter/pattern matcher like this, probably not. To understand the differences between all the load balancing, window resizing and congestion avoidance algorithms, as well as why and how they work, probably so.
As I say below, I bought a Win95 box in 1997, and it came with the "Win95 with USB Support," which is what I'm recalling here. That support wasn't all that hot.:-)
Windows 95, with all its warts and issues, was something of a high point. And, honestly, I do consider this from the vantage point of hardware built for Windows 95, running Windows 95 OSR2, or its closely related followon, Windows 98SE.
The launch version of Win95 was awful and nobody was really prepared for it and it caused plenty of problems. It didn't understand USB at all, etc. etc. etc. But, it eventually matured, and it really represented a fundamental mental shift for everyone: DOS is well and truly going away. You could manage things from a GUI. You don't have to set jumpers to install a card.
This was the first Windows that didn't boot into an obvious DOS first. It was the first Windows that started to feel more like a lot more than a graphical version of DOSSHELL.EXE. It was the first version you could credibly manage almost entirely by GUI, rather than editing obscure.INI files to comment out incompatible VXDs.
In terms of bringing the state of PC computing forward, Win95 was definitely one of the larger, more successful steps forward. If I had to rate the more successful steps on Microsoft's part, they'd be, in roughly chronological order:
MS-DOS/PC-DOS 2.1x: First widely deployed and long-lived DOS iteration. Adds subdirectories, device drivers and the EXE format, IIRC. Powered the generation of IBM PCs, PCjrs and the first wave of compatibles that really began to put the PC on the map.
MS-DOS 3.3: Probably the highlight of the DOS networking era. As I recall, this is the peak of the early LanManager attempts at networking PCs. Also brought many ideas from XENIX back into DOS.
MS-DOS 6.2 + Win 3.1x: DOS reaches its pinnacle, with proper online help, a decent compiled BASIC and highmem support. Windows finally begins to become something worth putting at the end of AUTOEXEC.BAT for many people. Some of this started happening with MS-DOS 5, but it didn't really reach maturity until MS-DOS 6.2x.
Win9x: Win95 was a much needed upgrade in interaction with the PC. Established a new UI that'd hold with minimal changes through XP (though it got a graphical refresh for the default XP theme, classic was still available). It finally made it reasonable for most people to dump DOS. It made managing the system entirely from the GUI credible. Though flawed, it brought us the first instance of Plug-and-Play and the end of the jumper. This alone was a pretty huge step. Combine it with USB, and you have a rather noticeable shift in ease of use at the hardware level. Granted, much of this didn't stabilize until around Win98SE, but in many ways Win98SE was really more of a Win95 SP4.
Win2000: This put the NT kernel on the map for most people, and many still run it. This set the stage for the successful release of WinXP.
WinXP: For all practical purposes, killed DOS dead for good by bringing the NT kernel to the masses.
I'm not sure whether Win2K and WinXP both belong on the list as separate bullets, or if they really kinda form a single bullet point. Their biggest contribution together was to kill DOS and force everyone to finally program with at least some hardware abstraction. <soupnazi>No direct hardware access for YOU!</soupnazi>
At any rate, if I were to name the highlights of the Microsoft path in terms of actually advancing the state of PC computing for most people, those would be the points I pick.
I'm not a Microsoft fanboi. I was something of a fan, if a bit timid about it, back in the early 90s. I quickly became disillusioned when I got to college and was exposed to UNIX. Here I was with a 386 all to myself that I could barely use without crashing, and I was logging into a timeshare AT&T SVR4 UNIX box with dual 486s, sharing it with 100 other people. In late 1993 I installed Linux and dual booted for a few years, but eventually I was running Linux only. So I'm no Microsoft apologist.
We have a pretty good estimate, on an order of magnitude basis. About 100 billion neurons, each with an average of 1000 synapses, firing 100 pulses/second.
And what's important to know is that we also know how quickly we can run mathematical models of these things with reasonable accuracy. So, if one presumes Moore's Law holds up, it becomes pretty simple to make a reasonable guess when we'll have sufficient compute power to directly model as many neurons as there are in the human brain in essentially real time.
The flip side of this, though, is that this ONLY provides the raw compute power. It doesn't automatically provide us with the knowledge necessary to wire it up correctly. Sure, the absolute details probably aren't necessary, but considering the wide range of human mental ability, ranging from non-viable/comatose to hyper-intelligent, I'd say the devil's in the details. Who knows how long it'll take to figure that out?
My understanding is that solar activity is increasing, which is warming up all the planets. The fact that that's happening concurrently with our rising CO2 levels is just wonderful.
Slashdot Mirror
I started with Mirsky's Worst of the Web, and graduated to Slashdot and FARK. Do I win a prize?
You know, that never ceases to lose its charm, particularly when a user with UID 'x' says it to a user with UID 'y', where x > y.
And I'm never sarcastic. :-)
I misread his comment also. He didn't *sign up* until after they had the ability to let you filter Jon Katz.
For the curious, I did some Googling and it appears the 100,000 UID mark was crossed a little before Oct 8th, 1999.
Can you set up a filter to auto label these, and does that keep them out of the spam bin? (Under "More Actions", see "Filter Messages Like These".)
It's inside out.
Maybe we need an infrastructure for this. An infrastructure that would be common among multiple languages. And then you could run any language that can target this common language infrastructure. And if you manage it properly it could be secure....
See, that's sharp isn't it? Of course, it might seem like I'm parroting a bunch of buzzwords in this monologue, but I really have a message... I'm not just making small talk. I think that's enough pearls of wisdom in one post.
--JoeOops, I see you said "decryptor." Of course, if you have that, then you've unlocked this key. But, how many keys does the virus have on its keyring and how quickly does it acquire more? It's not like it's a DVD, fixed in a medium or a CSS descrambler ASIC in a $20 DVD player.
RSA is asymmetric encryption. That's why the key-length is so long. It doesn't matter if you have the encryption key. You can't decrypt with the encryption key. Keeping the RAM hot is only helpful for trying to find the plaintext in a disk buffer somewhere.
RSA has much longer key lengths than symmetric encryption due to how the math works out: Only a small fraction of 1024-bit numbers make suitable keys. Encryption / decryption key pairs have very specific mathematical properties related to primes. (See the Wikipedia page the GP posted.)
It wasn't a microprocessor limitation in 1987 ("6 years later"--after the 1981 starting point). It was a PC architecture limitation and real-mode OS limitation. The 80286 came out in 1982 and could address 16MB directly. 80386 came out in 1985, offering 32-bit protected mode and VM86 mode.
Had PC's OS embraced these new CPUs' features more quickly and in a more integrated fashion, we might've avoided years of LIM-EMS, XMS, EMM386 and all the DOS Extenders. (GO32... DJGPP... How I do not yearn for thee.) We never got to have a protected-mode DOS, and Microsoft abandoned XENIX. OS/2 never caught on for some reason, probably because people didn't move from DOS immediately, and Windows provided a bridge, however shaky.
But I'm with you. He did make something of a classic mistake: He made an extrapolation that seems more linear than exponential, or at the very least had too small an exponent. But, he also had a time horizon. He was planning for 10 years, and 640K seemed like enough for that horizon.
--JoeFirst an OT "Howdy!": I think we've crossed paths before on LJ. (lj user=mr_z) Howdy. :-) BTW, where'd you go to school at? It appears we're from the same neck of the woods. Oh, and I turn 33 in a couple months myself.
Swinging back on to the subtopic: Probably one of the larger motivators for Segment + Offset addressing was so that pointers (or, at least the live portion manipulated during loops) could fit in a single 16-bit register. The 8086 was a 16 bit machine, and there was significant advantage to building small applications in a "near" model, and slightly larger applications that rarely dealt with objects larger than 64K.
The 8086 was architected to allow porting 8080 code to 8086 with a minimal translation. This is likely why the 16 bit registers are also addressable as 8-bit H/L pairs. The 8080 H/L registers themselves correspond to the 8086's BX, which explains addressing flexibility heaped on to BX. (As you may recall, the 8080 ganged these two 8 bit registers up to make a 16 bit indirect pointer register.) You might get a larf reading through that XLT86.ASM I linked above--it appears to have been translated by itself! (How's THAT for a test case?)
The segment-offset model also allowed for fixed offsets to be compiled in for "large aggregates" when coding for one of the "large data" models. Large aggregates are things like large arrays and large structs in C. This mode of course requires 32-bit pointers (which are really just seg:ofs pointers, so they only give you a 20-bit address space). This may've been what your professor was thinking of.
I know I've abused the various segmentation models before. I've even used the CS register as an extra data segment in loops that needed to address three separate tables that weren't in the same segment before. :-)
As for SPARC, it just uses a nice, linear, flat 32-bit address space for each task. 32-bit registers make it easy. Even UNIX works that way on 32-bit x86 machines generally. Pointers do, in a sense, get "hard coded," or at least fixed to specific virtual addresses, at final link time. Final link can be at program load time for dynamically-linked binaries, or before that for statically linked binaries.
--JoeThe A000:0000 thing is weird, of course, because at the time, the CGA and MDA mapped their memory at B800:0000 and B000:0000, respectively. (Don't confuse CGA with MCGA, which is seems to just be a VGA missing its left nut.) EGA and VGA were a ways off when 640K got settled on. Granted, IBM had reserved A000:0000 on up for peripherals, but it wasn't until EGA came along that an IBM video card used A000:0000 for a frame buffer.
A common trick for memory managers to break the 640K memory barrier was to map real memory into holes in the "reserved" area, and link those into the MS-DOS "memory arena." This worked by setting the top of arena to a higher address, and marking the regions occupied by devices as used. Since many programs needed large contiguous allocations, the next step often was to use said memory manager to load device drivers and other small things into these newly available holes, freeing up more of the larger "below 640K zone." You could teach later versions of DOS to put its disk buffers in this "upper memory area," aka UMA. (Not to be confused with the HMA. Ask the guy over there frothing at the mouth about "fast A20 gate" about that.)
All this brings back old memories. Anyone remember this?
A:\> debug
-gc800:5
Mmmm... 615 cylinders, 4 heads, 17 sectors. Lemme bust out OpTune and tweak the interleave. What? 5:1?!?!
Best forget the Bad Old Days.
--JoeNot to nitpick too greatly, but the form is gerund-animal, since the first word acts as a modifier.
:-)
I wonder how it compares to Digital Mars' implementation.
You clearly failed to get mine. Suitable you should hide behind "Anonymous Coward."
What about grammar?
That comment about stricmp is interesting. I assume it's bridging the difference between strcasecmp and stricmp. strcasecmp has been around for quite a long time and predates Linux. It's part of SuS.
(The reference above is the oldest I could find with a quick Google search.)
For a packet filter/pattern matcher like this, probably not. To understand the differences between all the load balancing, window resizing and congestion avoidance algorithms, as well as why and how they work, probably so.
As I say below, I bought a Win95 box in 1997, and it came with the "Win95 with USB Support," which is what I'm recalling here. That support wasn't all that hot. :-)
I bought a Win95 box in 1997, and it came with the "Win95 with USB Support," which is what I'm recalling here. That support wasn't all that hot. :-)
Windows 95, with all its warts and issues, was something of a high point. And, honestly, I do consider this from the vantage point of hardware built for Windows 95, running Windows 95 OSR2, or its closely related followon, Windows 98SE.
The launch version of Win95 was awful and nobody was really prepared for it and it caused plenty of problems. It didn't understand USB at all, etc. etc. etc. But, it eventually matured, and it really represented a fundamental mental shift for everyone: DOS is well and truly going away. You could manage things from a GUI. You don't have to set jumpers to install a card.
This was the first Windows that didn't boot into an obvious DOS first. It was the first Windows that started to feel more like a lot more than a graphical version of DOSSHELL.EXE. It was the first version you could credibly manage almost entirely by GUI, rather than editing obscure .INI files to comment out incompatible VXDs.
In terms of bringing the state of PC computing forward, Win95 was definitely one of the larger, more successful steps forward. If I had to rate the more successful steps on Microsoft's part, they'd be, in roughly chronological order:
I'm not sure whether Win2K and WinXP both belong on the list as separate bullets, or if they really kinda form a single bullet point. Their biggest contribution together was to kill DOS and force everyone to finally program with at least some hardware abstraction. <soupnazi>No direct hardware access for YOU!</soupnazi>
At any rate, if I were to name the highlights of the Microsoft path in terms of actually advancing the state of PC computing for most people, those would be the points I pick.
I'm not a Microsoft fanboi. I was something of a fan, if a bit timid about it, back in the early 90s. I quickly became disillusioned when I got to college and was exposed to UNIX. Here I was with a 386 all to myself that I could barely use without crashing, and I was logging into a timeshare AT&T SVR4 UNIX box with dual 486s, sharing it with 100 other people. In late 1993 I installed Linux and dual booted for a few years, but eventually I was running Linux only. So I'm no Microsoft apologist.
That said, you'd be
Isn't the microLenat the fundamental unit of bogosity in quantum bogodynamics?
And what's important to know is that we also know how quickly we can run mathematical models of these things with reasonable accuracy. So, if one presumes Moore's Law holds up, it becomes pretty simple to make a reasonable guess when we'll have sufficient compute power to directly model as many neurons as there are in the human brain in essentially real time.
The flip side of this, though, is that this ONLY provides the raw compute power. It doesn't automatically provide us with the knowledge necessary to wire it up correctly. Sure, the absolute details probably aren't necessary, but considering the wide range of human mental ability, ranging from non-viable/comatose to hyper-intelligent, I'd say the devil's in the details. Who knows how long it'll take to figure that out?
--JoeNo wonder I gave up on the moderation system.
My understanding is that solar activity is increasing, which is warming up all the planets. The fact that that's happening concurrently with our rising CO2 levels is just wonderful.
From on top of the shark, past the good guy, and right through the world domination device (accidentally), of course!