The protected mode stuff like DOS/4GW made programming a whole lot easier in DOS as well as you could simply address whatever memory you wished in a normal way. Where as before that, you had all sorts of hoops to jump through to use different areas of memory. I especially loved programming VGA mode, as doing graphics back then was as simple as setting a memory location for the video to a certain colour. But that's another topic. ;)
There is actually a 4th mode in 80386: the so called unreal mode. In this mode the CPU is behaving like being in both real mode and protected mode in the same time: you can access all the memory but you have no memory protection and you have your real mode segmented memory (but the segment size is 4 GB). This mode was also available on 80286. When you power up or reset a processor (even the newest one) the processor starts in this mode. This mode is switched off when the so called selectors (or segment) registers are given a value. To reenter unreal mode you have to switch to protected mode, set up everything then switch back to real mode, but without loading values into the selector registers. The other method is to use an undocumented LOADALL instruction. Some games like Ultima 7 used unreal mode, some BIOSes and to a lower extent Windows 3.0 and OS/2 1.x.
Wait. How could a 286 have flat real mode with its inherently 16-bit addresses? I understand how it could have HMA as the trailing end of the segment FFFF, that was what DOS HIMEM.SYS used. But AFAIK the 286 simply could not use more than 16 bits for offsets (so segments were limited to 64k even in protected mode, but they could at least start on higher addresses by the descriptors) so this address space ended at 1M+64k-16byte and that was all. What did I miss? Or you mean you could prepare descriptors for segments so they didn't start at every 16 bytes like in usual real mode? That might work but wouldn't be compatible with the original DOS programs anymore.
Yeah it's a little bit tricky. On the 8086/8088/80186 you had 16bit segment registers (CS, DS, ES, SS) the processor calculated a linear address from it: linear address = 16*segment_reg + offset_reg. Starting from the 80286 you had 16bit selector registers (CS, DS, ES, SS, FS, GS) and you had 6 96bit segment registers with the following structure (base (32bit), limit (32bit), permission and attribute flags (16bit), selector(16bit) corresponding to each selector register. The CPU used the segment registers and not the selector to generate the linear address: linear address = segment_reg.base + offset_reg; if offset_reg>segment_reg.limit then CallSegmentFaultHandler; In protected mode these values were loaded either from Global Description Table and Local Description Table when you loaded a value into a corresponding selector register. In real mode, however, these values were generated from the value loaded into the corresponding selector register when you loaded a value into it: segment_reg.base = selector_reg * 16, segment.limit = 65535. The keyword is 'when'. The LOADALL instruction would load the entire segment registers and not just the selector parts. So you could setup a segment while the CPU was in real mode with the base address being higher than 1MB. Technically, you could even setup a 4GB segment limit but since the 80286 had only 16bit offest registers it would not make too much sence. Until you loaded a new value into a selector register the corresponding segment register values were kept. On the 80386 and above you could switch into protected mode setup the segemnt register from the GDT then switch the protected mode off but "forget" to load the original values back to the selector registers. This trick could not be used on the 80286 since you could not switch off Protected Mode. (Well. Actually, you could with doing a LOADALL from Kernel Privilege, but then what's the point if you would LOADALL anyway.) When the CPU starts up the initial segment registers look like this: segment_reg.base = 0, segment_reg.limit = 0xffffffff, selector = 0. On the most BIOSes the Unreal Mode is not switched off and the real mode is entered by the small program located in the MBR and/or the BOOT SECTOR. The unreal mode is fully compatible with any real mode program until the program would change the selector registers. That would be especially problematic if the program's code would be located above 1MB. I hope that clears things up. Btw. to access RAM above 1MB you had to switch on something called A20 Gate. That's a collection from a very fast AND circuits one of its inputs connected to the Address Bus of the CPU and the other ones connected to an unused output of the keyboard controller on the mother board. I know this last sentence sounds weird but the A20 Gate is also a weird circuit. The HIMEM.SYS would turn the A20 Gate on when it was loaded. Thus, enablig the so called HMA where you could place both data and code and you could actually execute code from there. You could ask DOS to do that by DOS = HIGH, DEVICEHIGH=, LOADHIGH or LH instructions.
According to the Intel's documentation the Virtual 8086 mode checks for 64kB segment limits and it states that you can turn this behavior off, but the how is not documented.
So it's like you changed a segment register via LOADALL instead of LDS/LES and it retained its base address even if it pointed above 1MB because it was kind of forgotten. That sounds like a real way to address the entire address space but still required updating the segment register when you ran out of the actual 64k offset limit. I hope I understand now. Still, it's very far from the very convenient 386 flat real mode with its up to 4G limits and 32-bit offsets.
@@TravisFabel The 386 could adress up to 4GB. As in 4096MB. But I doubt the bios or the motherboards that the 386 was delivered with could come close to supporting that.
Geir Eivind Mork it is the memory controller that recognizes a certain number of simm’s having dram chips with specific row and column address pins. In first and second generation pentium era, 1995, the normal memory controller recognized 4 simms (some 8?) and did work with 16 mb Simms. It had a provision for 64mb , but did not work with the dram chip arrangement. There were special controllers for multi processor systems for 1 gb
I love that you don't just give the history, but also describe it and how it compares, or in this case applies, to modern computers. Came to learn about DOS history and learnt about a feature of modern computing as well!
The proper crazy part is that every x86 cpu, including modern current day core i7 cpus start up in Real Mode. So your fancy gaming machine first powers on thinking it is a multi gigahertz 8086 about to run DOS. Fortunately for the sake of humanity the UEFI or the OS switches it into protected mode so the modern world can function. So sit for a moment and imagine a world where we still used DOS on our computers, and conventional memory was still a relevant concept. I imagine himem would take a while to count 8 gig of ram.
I forget what the last machines actually able to boot real mode DOS were - I know the early Athlon64s and Core 2 Duos could. Any 64-bit chip with a BIOS rather than UEFI, IIRC. Of course, actually booting DOS on the metal became mostly useless after ISA slots went away, but hey, it's there. The last few things it was used for - firmware updates - now usually use some species of Unix kernel to do their thing.
It's more a feature of the BIOS/motherboard firmware than the CPU itself. Most EFI implementations support legacy boot (which, as far as I know, still lets you boot real mode DOS) through a piece of software that emulates BIOS and dumps the CPU in real mode. And, of course, you can start up a virtual machine and boot real mode DOS effectively running natively on the CPU still.
such a world would be awesome, I wish microsoft kept the "DOS + GUI" model instead of switching to NT!! :D hahahaha. if they wanted they could make a DOS capable of adressing big ram, using ntfs or a "fat64" and everything needed today.
I actually ran msdos and windows 3.1 in my i7 4500u and 8gigs of ram. But it couldnt adress that so i got down to 4gb and it didnt recognize all the ram but didnt crash. I played wolfenstein with the pcspeaker. It was cool
God, I learned to program on an XT but wanted a 386 or 486 so much when i read about protected mode. I honestly remeber thinking no one could ever use 4gb of ram, 32 bit address space would be as big as it would ever be. I wrote an attempt at multi threading by having the timer interrupt push some registers onto the stack and then switch to another sub routine, run it a bit and back again. The "time slice" had to be in seconds, as I remember it, because the XT was so slow. I had two "threads" which just output a 1 or 2 to the screen continuously to show they were active and when one day I got it to run for about 30 seconds before crashing I felt like a fucking genius. Oh, good times. Now the only programming I do is little VBA macro code to automate stuff at work. Great vids BTW. Reminds me of happy times as a teeenager.
If it crashed, then most likely you had a stack overflow somewhere. I think it's an imbalance push and pop, because 1/18.2 second is more than enough time for 8088 to push and pop the registers several thousand times if not more.
Very cool video indeed! I was always confused by all these different modes, but this video cleared it up for me and now I know a little bit more about vintage computers. I love these series! Please keep making more!
Thanks for this great explanation! All those times I did that protected mode thing on my old 386 I had no idea what it really did. All I knew was that it enabled use of the rest of the memory. lol
After some game failed to start I figured out it runs with an another version of DOS/4GW. So I started to collect them and a few other DOS Extenders and several libraries (like sound). They've came handy with my demo mania.
it is incorrect that the requirement of asking (allocate) memory from the O.S. is unknown. the DOS has a special "int" function (21h) that serve this function. It does allocate a specified block size of memory and returns a pointer to it.
I already knew most of this stuff before coming to this video but I just wanted to say this was a really nice and well put together summary. I liked it a lot. You should cover things like "Unreal Mode" sometime.
Thanks for clearing this up. Was taught this in school in 95, when I was at a tech college. I had simply forgotten the basic's of this knowledge. Good video. Thanks.
When I was in school in early 90's in a small rural school in Finland, we had (already then) ancient PC's with 80186 processors made by Nokia. I hadn't seen those CPU's used anywhere else and never understood why they were used on those computers (called Nokia MikroMikko [something]). But now I'm thinking it could have been that Nokia had other uses for those CPU's and wanted to use same components in multiple products. The PC configurations were odd also in other ways, in hindsight kind of like lots of leftovers had been used in making them. (To be clear, the computers probably were OK by performance when they were sold. The school just kept the computers way over their age.) Back then Nokia made toilet paper, paper towels, tyres for cars as well as for heavy machinery, rubber boots, and various electronics for consumer and industrial use. Later Nokia ditched the other businesses to concentrate on mobile technology, which went well until competitors from Asia got going with cheaper prices, after which Nokia tried with Windows Phones... Anyway, the earlier ditched businesses still seem to be running fine by other names as independent companies. I guess things just don't always go as expected.
Actually memory extenders on 286 used the LOADALL instruction to access memory from himem and copy it to lomem which didnt involve entering protected mode at all. Dos apps also DID request RAM from the OS when allocating RAM. Remmeber TSRs? Dos apps werent necessarily the only ones in memory. There had to be a way to protect RAM even in DOS it just couldnt be enforced. I actually wrote a complete multitasker for DOS when i was a kid which rivaled DesqView. Toughest coding job i have had to this day! :)
I remember using the Watcom C++ compiler. It was just hello world, I hit compile, ran it, and I saw the DOS/4GW banner. It was that easy to have in a program
The mean reason for the extenders was that you needed to fiddle about with changing some of the interrupt stuff when you switched from real mode to protected mode. Real mode and protected mode interrupts are a little bit different. For example if you where running dos and you needed to go to protected mode but wanted to still use the gfx card bios interrupts you needed different code. Dos4gw had that code and was able to do the conversions for you. This is from memory and some of what I'm saying might be slightly wrong. The dos4gw code also had the page file stuff built into it as well. It was rather slow on a 386/486 but was possible. Desqview was fairly awesome back then as well. The old dosshell was ok in a pinch.
I remember reading about 2 different methods of DOS access to extended memory: DPMI (DOS Protected Mode Interface), which was compatible with being run in a virtual DOS machine on OS/2 2.x; and VCPI (Virtual Control Program Interface?), which wasn't.
But those games really weren't using the memory protection, and systems like Amiga OS, Atari ST and Macintosh System 7 were running multitasking desktop window systems quite happily on 68K processors without a hardware protected memory management component. (the LC, and EC 020 and 030 processors, as well as base 68000 / 68010) I say "quite happily", but by that I mean Bombs and Guru Meditation were still less common than the dreaded BSOD of any version of Windows still running under a DOS extender. (EMM386.SYS, in most cases, though you'd get better traction from 386MAX, QEMM or DR-DOS EMM386.EXE) I also say "multi-tasking", when in actual fact the Atari ST/TT and Macintosh were actually "task switching" OS, supporting scheduling and true multi-tasking only co-operatively, and _only_ for "desk accessories", and not full applications. That still leaves the Amiga, which really was pre-emptively multi-tasking, so the _only_ caveat that I have to make _there_ is that the PAD (Paula, Agnes and Denise) custom chipset (specifically Denise, in this case, IMS) had "memory management" and "thread management" as a core functionality, extending the capability of the main processor. But she could still only control, and report upon what was going on inside the "chip RAM", because she didn't support the full address range of even a basic 68000 processor. (RISC OS, on the Archimedes computers _was_ always pre-emptive multi-tasking, even before it got a desktop GUI in RISC OS 2, but I believe even the original ARM 1 processor had a memory manager ... I _think_, but I didn't get to it until RISC OS 3, and never managed to crash the MMU, even writing GUI code in assembler, so I'm not 100% sure on that history) *Key terms*: (for students) _Pre-emptive_ multi-tasking is when the OS dishes out slices of processor time to processes, potentially prioritising one process over another, in response to hardware interrupts and set triggers for "real-time" reaction. _Co-operative_ multi-tasking is when each task does what it needs to do, and then executes an API to tell the OS that it can let another task do some work now. A bit like when you have a camp fire meeting, and pass a stick around to decide who can speak, but the person holding the stick doesn't have to give it up until they're done talking.
The PAD chipset had no such capabilities. The PAD chipset could address the first 512KB to 2MB of "CHIP" RAM as a flat address space, overlapping the 68K's address space, allowing the CPU and Agnus chips equal access to graphics data. The Amiga 1000, 500, 2000, and 2500 literally had *no* memory protection capabilities on stock configurations. You literally needed to install a 68020 or better accelerator card in order to even entertain the *thought* of using an MMU (which most people left the MMU sockets empty). Thread management was exclusively the domain of exec.library. It's a purely software construct (and still is today even on the most heavily memory protected systems). The chipset had nothing to do with it. Memory management was also the domain of exec.library, again without any help from the surrounding I/O hardware. Exec maintained a free list of unallocated blocks of memory, some of which were identified with certain flags (c.f. MEMF_CHIP and MEMF_FAST, etc.). When you invoked AllocMem(), you always told it which kind of memory to allocate the second parameter (e.g., xyz = (BPTR)AllocMem(1024, MEMF_CHIP | MEMF_PUBLIC)). Whenever you installed memory cards, expansion.library would interrogate the autoconfig ROMs on the boards for memory regions and their flags, which always had MEMF_FAST set by the way, and would amend the kernel's free list during autoconfig time (when the screen is grey during cold boot).
Correct. I programmed against it as such, treating it as a black box that just worked. Also, I've never reversed exec.library to find out what it's _actually_ doing. What I _do_ know is that early x86 Amiga emulators for DOS struggled to emulate the PAD accurately enough, in a timely manner, for exec.library not to fall over. I've read some of the AROS developers lamenting the lack of hardware PAD to re-create exec.library, and I know there were 030, and 040 software exec.libraries I used to use which documented moving "memory management" off the PAD, and on to the MMU in the CPU. IMS, what they said was that the chipset was used to help swap out registers between threads, and to help detect illegal memory operations. However, without a proper MMU, it still couldn't stop the CPU _before_ it corrupted other space, (illegal operation) it could only detect that it had done it during the next thread cycle and halt at that point. Something like that. It meant that multitasking on a 68000 / EC0x0 processor was more efficient on an Amiga than, for example, an ST, or Mac, but didn't mean it was any less prone to requiring you to reboot. Of course, the default OS on ST and Mac didn't have multi-threading, and only really switched tasks in response to user requests, but that didn't mean you couldn't run a "proper" multi-tasking OS on them. ;) (I had an ST too, and used an Mac LC20? at work) I used a full 040 board in a A1200, (it died) and have a full 030 in my A4000. I _really_ appreciated the yellow gurus which returned to the desktop killing off the offending app without forcing a soft reboot, but they didn't really kick in until I replaced the exec.library with the appropriate software patch version, and became better with some of the 3rd party versions which would convert the yellow guru into a nice reqtools / MUI dialog. The later, with a proper thread mini-dump! :D Very handy.
There is also more to protected mode than just access to memory. Due to the way the segment registers turn into selectors instead and being able to access a 4gb chunk of memory with just an offset register instead of having to read a 64k block then move the segment forward and repeat, this enabled much higher performance and simpler code. (I am.talking 386+ protected mode here)
Thank god those days are over. When CPU changing the running mode means there wasn't any debuggers on the market that can be used for tracing the system code. So writing code that puts processor into protected mode meant many days of assembly code reviewing - this was the only way to debug at the time until affordable ICE chips came out on the market. All that changed with DOS extenders. Using DOS4GW (Tenberrys Software's DOS extender for Watcom compiler) assume that once processor is in protected mode, the application stays in protected mode and it allowed stepping through the code. All dos interrupt services were done in virtual 86 mode. This worked beautifully as long as the program stayed in protected mode. Before DOS extenders, we used Expanded Memory Manager device drivers. Basically memory is written to a small mapping zone, then you ask device driver to go into protected mode and copy the 64K chunk (Divided into 4 banks at the time) to extended memory (memory above 1MB). To address the content you would have to issue swap (copy from extended memory to your zone) before accessing the memory - that was pain in the butt but it did not last long.
Important to note that the 286's extended memory of 16MB of address space was only accessible via 64KB segments, just like the 8088/8086. Flat memory didn't arrive to the x86 world until the 386.
Also though, great vid. You explained away a lot of the gibberish from the boot screens of my youth. Things I didn't realize I wanted to know about until I just did.
yup, the 80186, intro'd in 1982 and would have be the replacement of the 8086 in PC's. However (and Wiki-quote here) "because its integrated hardware was incompatible with the hardware used in the original IBM PC, the 80286 was used as the successor instead in the IBM PC/AT." And; "The Intel 80186 is intended to be embedded in electronic devices that are not primarily computers. For example, its offshoot, Intel 80188 was embedded inside the Intel 14.4EX modem released in 1991. The 16 MHz processor was used to perform complex algorithms needed for forward error correction, Trellis coded modulation, and echo cancellation in the modem. In May 2006, Intel announced that production of the 186 would cease at the end of September 2007.[4] Pin- and instruction-compatible replacements might still be manufactured by various third party sources.[5]" en.wikipedia.org/wiki/Intel_80186
i think those weren't that popular, however the "microcontroller" version of it was far more used. i had at least 4 or 5 PCBs of random peripherals (ISA cards, tape drives, scanners, and so on) that uses the 80C186.
Yup! I believe a few computers made use of it, and it was broadly similar to the 8086. However there were incompatibilities with the existing chipset and the machines incorporating it were rather niche.
Great informative video! Altough I am a little bit confused now. DOS 6 has these drivers called HIMEM.SYS and EMM386.EXE that lets you use memory above 1024K (and between 640K and 1024K). Is this for real mode only then?
Himem.sys exploits a bug originally created in 286 processors which mapped the first 64kb of extended memory to it's 20th address line. You can therefore shift (or swap) parts of conventional memory into this High Memory Area to alleviate the 640Kb memory constraints, but you can't execute code within it like you'd be able to in protected mode. EMM386 emulates an earlier expanded memory standard (EMS) using extended memory (XMS), and allows you to load drivers from conventional memory into a high memory area between 640k and 1024k by mapping this memory... I discuss EMS in this video th-cam.com/video/zUvsER6l56Q/w-d-xo.html
Early Intel cpu modes were a pain in the butt to program for. Motorola and others had the right idea. The 6502 series, for example, was the king of efficient and logical code organization and execution. Assembler for that chip just makes a lot more sense with no worry of program and data segments, protected or real modes, etc. I would love to have seen a progression of the 6502 to a 32 bit data and address bus with the same level of code efficiency, but alas, that didn't happen.
I remember operating UNIX System V for 80286. There was also a Microsoft-licensed version of UNIX called Xenix that was made for the 80286. They were the precursor of Windows for Workgroups in a sense, because Windows could not yet run networked applications - UNIX and Xenix could.
I remember that in 286, the protected mode was a one way ticket. You can get there but you cannot return to real mode, except if you reboot the system.
It is essential for any multitasking OS to have a protected memory mode? Well AmigaDOS managed to multitask without one quite successfully. Admittedly it did mean any badly written software could bring the whole system down like a house of cards, and developers used Enforcer on 68030 onwards to debug their software so it played nicely. Also I seem to remember that the method of pre-emptive multitasking the Amiga used required protected mode to be switched off to work properly. As it was developed from TripOS onto chips without a protected mode it's bot surprising that protected mode would have interfered with its workings. They probably should have developed memory management in software to get around the issue. Didn't someone develop a version of DOS for the PC which could multitask? How did that work?
There are still hardware "experts" out there who claim that DOS is more than capable of accessing memory beyond 1 MB in Real Mode and defend their claims wildly. Dealing with these people can be... annoying, to say the least. :P
yes, that is correct, it is called HIMEM.SYS which allow by through an API to access that higher memory. And where it maps the current page in view?, in the address space of the memory hole, IIRC 740K-1024KB addresses, well that is left after the hardware takes its bytes..
the standard is 0 up to 720KB (720KB not includes) is RAM, upper from that is EMPTY space addresable to ISA cards, so, the video card video memory is accesable by that memory hole, and others cards too.... but including having all FULL of card, there is still an unused address range, that is taken by HIMEM.SYS...
+flyguille Yes, BUT, HIMEM.SYS achieves this affect by temporarily switching the CPU into protected mode then back again, which creates the illusion that Real Mode can itself access memory beyond 1 MB when it can't. :P
I don't know if you're still running this channel as I've asked quite a few questions but here goes another one...Would an extra processor for the protected memory help run several programs at once on say a...286? Can they use a virtual core today to speed up the protected memory while running say...Office 365?
Not sure if it is just me, but I do not understand what you are asking and why? What are you wanting to do with this hyperthetical modified 286 and why?
@@ksp1278 The question was about running a much faster processor than the 8088 in protected mode. I want to know if it's possible to say emulate a 286 today entirely on a virtual core? I want to know how far I can push it before the whole thing breaks.
@@Sinn0100 I am sure that modern PCs are fast enough to be able to emulate a 286. In fact DOSbox is a kind of emulator for DOS software such as that designed to run on hardware like a 286. But I don't think that's what you are asking is it?
@@ksp1278 No but that's okay man! Thank you for the awesome response. Too be honest, I'm quite sure what I want either. I'm now infatuated with recreating my old cloned 486DX2 that I had as a kid. I have it almost completely together. Finally, I can play Doom on a....oh wait a minute, everything runs Doom now. ;)
@@Sinn0100 I am similarly trying to create some PCs to relive my childhood. In my case my first DOS games were Prince of Persia, Wolfenstein 3D, Duke Nukem 1 and Wing Commander 1 up through to Quake, Duke Nukem 3D and Privateer 2. I am creating 2 PCs to run those games. Both PCs are made from laptop motherboards. 1 is a Pentium MMX 166Mhz. That can be slowed to around the speed of a 386 by using setmul utility. For late 90s DOS games I have a 400Mhz Pentium III laptop motherboard. The main problem with laptops is lack of CD audio in DOS (They laptops I chose DO have soundblaster Pro compatability so can play midi and standard audio). I am yet to work out a solution to that CD audio problem. For Windows 95/98 games I am using a 2.0Ghz Pentium M based laptop motherboard with Radeon 9000 graphics. I am using laptop motherboards due to space constraints. My wife does not approve of me collecting old tech! Lol. So I have to keep it hidden. Haha.
if I recall correctly EMS don't need protected mode: there's facilities in the DOS (interrupts) to page in and out ofr XMS/EMS. So technically the barrier of 1024kB was not really a limit :)
It depends on the type of EMS or rather where you're getting that EMS from. As I'm sure you probably know, EMS stands fro Expanded memory system. Way back in the beginning, when you had only the 8088/8086 processors, which could only run in real mode and only had a 1MB physical address space, the only way to have expanded memory was an add-in ISA card that had additional memory on it. That memory was bank switched and was mapped into the existing address space through a small window. You accessed different banks of the memory by writing a number to a port which switched which bank was mapped into the window. When 386 processors came out, Dos came with EMM386. EMM386 was a device driver that loaded into memory and emulated all of this and enabled you to use extended memory as EMS. What's really happening there is EMM386 is using protected mode and doing it all for you in the background. In fact the "protection" of protected mode is what enabled EMM386 to do this. Protected mode didn't just protect memory access, it also protected input output ports. So, in protected mode if a program attempts to directly access an input output port it generate an exception or a protection fault just as it does when a program attempt to access a memory location outside of it's space. An exception is handled like an interrupt in that there is a pointer in the interrupt vector table that points to a location in memory where code that handles that exception exists and the processor immediately jumps to that location and executes that code. So, in the case of EMM386 that exception handler would be triggered whenever a program attempted to use expanded memory and EMM386 would then take over and handle it accordingly. Anyway, if you use EMM386 for EMS, technicaly you are using protected more or at least EMM386 is using it to emulate it.
@@unperrier5998 "Protected mode is not a pre-requisite to EMS" No, it's not a "pre-requiste" if you have an old 8 bit ISA card sitting on an slow 8 Mhz ISA bus with whole bunch of slow memory chips on it which are mapped into a small window in upper memory. Those cards were only 8 bit 8MHz ISA cards because they were made for the XT which only had an 8 bit 8mhz bus. When the 286 and 386 were introduced those cards were obsolete and nobody in their right mind would ever use one in anything but an XT. Instead they used software like EMM386 which emulated it, because it was much faster, and for that protected mode was a "pre-requisite".
Still waiting for a fairly modern browser for DOS using a DOS extender. Modern DOS Box-X uses a free DOS Extender (HX-DOS) for a port to DOS. Yes emulating DOS in a DOS OS :-)
Obviously. The operating system is what controls everything in the background. But DOS-applications did not expect to share the totalt memory with any other program. Many DOS-programs were written to use specific hardcoded addresses in memory. That will never work in a multitasking system.
Funny you show Windows 3.1 while discussing protected mode... Windows 3.1 has incredibly bad memory separation between processes. As in... absolutely none. Memory separation between processes didn't happen until Windows went 32-bit.
I was told, yet I couldn't verify it, that IBM OS/2 made use of the 286 protected mode and tweaked it a lot, to be able to return to real mode without a complete reset of the 80286 chip. Anyhow, all theses tweaks weights a lot on performance, wich can explain a bit why OS/2 failed where Windows NT succeeded.
1:21 That's not entirely correct, if you have a 286 executing code at FFFFF, it will continue on to 100000 rather than rolling over to 00000, unless you're on a PC (where the A20 gate applies)
Never mind all this hardware talk, that's leodard's mom from bi bang theory at around 4:11. Christine baranski and there's nowhere she's credited for this appearance. Not on her imdb, wiki, anywhere! Also my first computer was a Vic20 as advetised by captain kirk himself! I'm that old.
Ah Rise of the Triad!!! Our entire engineering team ended up playing after work until something like 10pm when the owner's wife called the cops on us because she heard screaming in the building. I was the lucky one to have the cop bang on my office window with his batton. Those were the days.
lol, think I answered my own question with google reverse image search - rhodesmill.org/brandon/notes/unixpc/transfer.html I'm pretty sure I had to use this interface at a workplace in the 90's!
The immportant thing dos extenders did was allowing the program to communicate with dos. not going to be able to do much if the program can't read files access the disk becaause protected mode broke things
3:26 Technically, not *essential*.. Just a jolly good idea, since it enables the OS to terminate malfunctioning software instead of potentially allowing them to take down the entire system.
aarrgghh - 80286 selectors and call gates and no-exec flags on a selector and swapped-out whose size on the selector up to 64Ki... so glad they scrapped most of the old protected mode in 80386 and made a page system instead
I used to have a program for my still video capture card. No os pure 286 protected mode. Virtual 8086 on the 386 doesn't exist anymore in 64bit cpu. It's now protected mode (32bit) and Longmode (64bit).
And this is the legacy that 40 years later has crippled every x86 processor and the entire general computer market. Intel and AMD need to totally dump backwards compatibility and start over from Day One designing an entirely new processor, that can truly take advantage of the advances in physical CPU manufacturing...
I still have nightmares about ultima 8. I needed 8megs of ram free and I had one partially bad memory chip, so I only had about 8000k total. It drove me crazy that 8000k wasn't 8192k so even with QEMM, bootdisks, etc. etc. I couldn't free up enough memory for Ultima 8. I never played it but I had dreams of how awesome it would have been... Sigh.
You are wrong about the DOS memory model. There was a call to DOS to allocate or free memory. mov ah,048h ; function number mov bx,1 ; how many 16 byte chunks int 21h was how you asked for memory. ax would be the memory segment for the new allocation. If you didn't do this, DOS could lock up when your program ended.
Yeah but if you wanted to could make a pointer to any address in the memory space and read or write there. Everyone overwrote the damn interrupt table as I remember it. In protected mode you couldn't do that unless the operating system said you could.
Peter Quint: The mistake in C of making the "null pointer" zero was what lead to that bug mostly. If you dereferenced a null pointer, you wrote to low memory. Badly written code was about as common in those days as today. I wrote a lot of code in those days. One that I thought was quite clever was a little TSR that allowed the printer port inputs to be used as contact closures that made switches appear to type stuff. Among the uses was to make a foot-switch page down through the instructions while you did something with your hands. I also wrote a multitasking addition to DOS with "multi" being two. It allowed one operation to run without user interaction while the user interface ran doing other stuff.
Protected mode... Aka 32 bit mode, more or less. I think... From memory. In any event some aspects of it are similar to what you see with the 65816 which is compatible with the 6502. It starts up in a mode where it behaves identically to the older processor until you issue an appropriate set of instructions to switch it. The x86 CPU is similar, in that it starts of in a mode that is basically equivalent in behaviour to the original 8086... Even modern processsors like a core i7 still do this. Backwards compatibility does weird things huh. Anyway, enough of my random stuff, go watch the video and see a probably much better explanation. (if nothing else because it was probably actually researched and scripted, rather than my off the cuff remark going wholly from memory... XD)
What is protected mode? Those god damn SIGSEGVs that happen when debugging a new program for the first quite a few times XD (Don't take this too seriously though XD)
Totally annoying thing when I have used Rhide. But Pascal was even worse, you will declare an array of 20 and you will end asking for the 20K position because a bug. Sometimes Pascal would drop into DOS badly, no message, no nothing, probably lost all the changes. Sometimes crashed the whole system to the point it self reboot. With protected mode the IDE was able to catch this things and stop them to avoid problems. But the first steps on it, with this criptic SIG events, pain in the ass to trace where the hole was. But ... sometimes DOS itself terminated the IDE (i.e. the debug sesion) before the IDE was able to catch the issue. Once you were quick out, no clues at all. The old time, long hours in the IBM PS2 with the clunky keyboard. What a tank.
XD When using C#, SIGSEGV would trigger an exception, but in C++, it's like, WAT, the program just crashed and I have no idea where it crashes... I'm not that sure how PASCAL works, as I only used that for like, well, 3 days I guess, not to mention there's already no need to use that language for anything. But, what kind of bug would result in accessing the 20,000th element in a 20 element array? I can understand having "off by one" bug, accessing of NULL pointer, and use a pointer that's not initialized, but, why trying to ask for the 20K? Also, that's exactly why you should always save before compile, I guess XD
LOL, just imagine it is you first try at programming, and your end condition faillled or never existed, so you keep reading and writting far from the boundary. Borland Pascal was used as a learning language, more or less like BASIC, it was pure DOS thing. For this enviroment, pointers were UNKNOWN, but you could trash the memory to the hell and the IDE was blind about that. It just keep going until something at DOS level exploded. It easy to have bugs like that when you are trying programming for the first time and the IDE is SO OLD that doesnt care about memory. Also, pascal input routines were total garbage. C input scanf is WAY more secure and consistent. Pascal crashed if you type a letter when a number was expected. It was up to the programmer to validate input at that level. Of course C# is another world. You cant even think in pointers anymore, is the way it works. Also, Visual Studio got so SMART through the years that is even catching small bugs while you are writting, FAR from a non declared or initialized var, it catch unreachable code, lack of return paths. Im using 2010 PRO edition, cant imagine the last edition. More like the IDE helps you to programming. But the paradigm changed, before, you write functions. Today you still do, but .NET framework will do most of the "old days" work for you with tons of methods so are now focused in more complex apps that integrate DB ... WEB etc. Of course never got a kick off from Visual Studio. It just halts at the point and let you know you mistake. I wont close suddenly. But VB6 ... it was more like PASCAL. Example, just write code used a var that is not declared .. NO PROBLEM !!! it will run anyways and eventualy when this part is reached just crash or get unexpected results. But at least will warn about walking outside boundaries. Pascal ... WONT ... just try it for curiosity. If you wanted to trash DOS until it reboots itself, no probs, you could. Not clear to me but like it was not using protected mode. As I told, the PC was the venerable IBM PS2, 4MB I think, with the IBM C O L O R monitor (wow) running PCDOS from IBM.
Back in DOS era, when you are running a program it takes ALL of the resources so, it won't quite be an issue if you crash DOS somehow. And if the input routine can cause crashes I'd say just switch to another compiler. But, I don't think there's anything else available besides Borland Pascal. I ended up didn't get too far into that language simply because it looks weird and that's it. In fact, the only two things I remember about it are, it uses "begin" and "end" for scoping, and ":=" for setting value. C# still has pointers, just, it's not working completely like in native C++ (C++/CLI is a thing so have to say "native here). You can only use a pointer when you fix a variable to a native memory area, otherwise .NET assumes that it can move the storing location of that variable without telling anyone, as it manages the accessing of that variable for you. As for IDE, I'd say that the main reason I prefer C# over other languages is simply, Visual Studio is awesome. And I think that the "IDE helps you program" thing is absolutely reasonable. If I have to do something else every time I do something anyway, why not just ask the IDE to do that for me? Machines never go tired but I will. For standard libraries, well, if there's not one available you mostly would just copy one that somebody wrote a million years ago anyway. For VB6, I think every expert would tell you to use the god damn "Option Explicit". I mean, why not? Without that, any typo would ruin the whole program and there is absolutely no error to be shown. If any book out there tells people not to use Option Explicit I would instantly hate the author of that book.) By the way, I'm using VS2015 Community since I'm not working in a big company or something like that.
LOL Borland Pascal was SO WEIRD. But, you know, they insisted it was the right tool. Crazy because I learnt that in 2000 and working in DOS machines was no sense. They told you that it was the best choice to teach programing ... well, not to me. The next curse we moved to C and used RHIDE that is djgpp on Windows. It like a Borland front end using gcc and gdb tools ported to DOS that run in protected mode only. I started with C# not long ago. I need to work on an ALREADY EXISTENT project and I was mad about not being able to use pointers. Pointers are still there but the code is unsafe and eventually, the power of the .NET framework and all the mechanism that allocates and free memory wont protect this part of code ... Plus, I cant start using pointers when other modules never did, just because tidyness an using an even criteria. So I worked my way, using either byte arrays or strings. Eventually sending or receiving an struct from or to a buffer, a simple thing that only requires a cast it is a torture when pointers are not used. Managed to get thing going with string and byte arrays. Also, I couldnt figure out how to declare structs, I ended creating a class just to hold the data structure .. which ... I dont like. But my boss eventually preferred this approach. It a great tool, powerfull and well used, you type little code. I always look at Stack Overflow for the best approach when doing something, discovering that one or two lines can be enough to solve a nice piece of code. And as you said machine wont get tired, Intellisense is there checking whatever you write is valid or not.
![Why does DOS use 8.3 Filenames? [Byte Size] | Nostalgia Nerd](http://i.ytimg.com/vi/eGIyCD2_qA8/mqdefault.jpg)
![Why does DOS use 8.3 Filenames? [Byte Size] | Nostalgia Nerd](/img/tr.png)
![Why are Floppy Cables Twisted? [Byte Size] | Nostalgia Nerd](http://i.ytimg.com/vi/CIfS6YKIf-U/mqdefault.jpg)
FIRST!
i am the worst
You shouldn't be so hard on yourself. You are clearly the best on this occasion of "THE HONOUR OF FIRST" and therefore earn your pinned comment.
You are a magnanimous man and I salute you.
Spanky Pants i feel sorry for you, since disabled people cannot enjoy life fully
damn. Missed by only 6 years
When I was a kid, I was excited to see the letters DOS4GW before a game opened because it meant the game was good!
True, but I had mixed feelings about it. I never wanted to read the words "page granular" after being kicked back to DOS losing unsaved progress...
I've seen this word "DOS/4GW" so many times it has literally burned itself into my brain.
Oh I wish that was true :-D there were so many crap games that used DOS/4GW ;)...
As someone who grew up in the 80s + 90s using these things, this channel is bloody ace. Full on Nostalgia.
And now these days we use "long mode". DOS/4GW might be one of the best extenders I ever used when making some programs. So versatile.
The protected mode stuff like DOS/4GW made programming a whole lot easier in DOS as well as you could simply address whatever memory you wished in a normal way. Where as before that, you had all sorts of hoops to jump through to use different areas of memory. I especially loved programming VGA mode, as doing graphics back then was as simple as setting a memory location for the video to a certain colour. But that's another topic. ;)
There is actually a 4th mode in 80386: the so called unreal mode. In this mode the CPU is behaving like being in both real mode and protected mode in the same time: you can access all the memory but you have no memory protection and you have your real mode segmented memory (but the segment size is 4 GB). This mode was also available on 80286. When you power up or reset a processor (even the newest one) the processor starts in this mode. This mode is switched off when the so called selectors (or segment) registers are given a value. To reenter unreal mode you have to switch to protected mode, set up everything then switch back to real mode, but without loading values into the selector registers. The other method is to use an undocumented LOADALL instruction.
Some games like Ultima 7 used unreal mode, some BIOSes and to a lower extent Windows 3.0 and OS/2 1.x.
Wait. How could a 286 have flat real mode with its inherently 16-bit addresses? I understand how it could have HMA as the trailing end of the segment FFFF, that was what DOS HIMEM.SYS used. But AFAIK the 286 simply could not use more than 16 bits for offsets (so segments were limited to 64k even in protected mode, but they could at least start on higher addresses by the descriptors) so this address space ended at 1M+64k-16byte and that was all. What did I miss?
Or you mean you could prepare descriptors for segments so they didn't start at every 16 bytes like in usual real mode? That might work but wouldn't be compatible with the original DOS programs anymore.
Yeah it's a little bit tricky. On the 8086/8088/80186 you had 16bit segment registers (CS, DS, ES, SS) the processor calculated a linear address from it:
linear address = 16*segment_reg + offset_reg.
Starting from the 80286 you had 16bit selector registers (CS, DS, ES, SS, FS, GS) and you had 6 96bit segment registers with the following structure (base (32bit), limit (32bit), permission and attribute flags (16bit), selector(16bit) corresponding to each selector register. The CPU used the segment registers and not the selector to generate the linear address:
linear address = segment_reg.base + offset_reg;
if offset_reg>segment_reg.limit then CallSegmentFaultHandler;
In protected mode these values were loaded either from Global Description Table and Local Description Table when you loaded a value into a corresponding selector register.
In real mode, however, these values were generated from the value loaded into the corresponding selector register when you loaded a value into it: segment_reg.base = selector_reg * 16, segment.limit = 65535.
The keyword is 'when'. The LOADALL instruction would load the entire segment registers and not just the selector parts. So you could setup a segment while the CPU was in real mode with the base address being higher than 1MB. Technically, you could even setup a 4GB segment limit but since the 80286 had only 16bit offest registers it would not make too much sence. Until you loaded a new value into a selector register the corresponding segment register values were kept. On the 80386 and above you could switch into protected mode setup the segemnt register from the GDT then switch the protected mode off but "forget" to load the original values back to the selector registers. This trick could not be used on the 80286 since you could not switch off Protected Mode. (Well. Actually, you could with doing a LOADALL from Kernel Privilege, but then what's the point if you would LOADALL anyway.) When the CPU starts up the initial segment registers look like this: segment_reg.base = 0, segment_reg.limit = 0xffffffff, selector = 0.
On the most BIOSes the Unreal Mode is not switched off and the real mode is entered by the small program located in the MBR and/or the BOOT SECTOR.
The unreal mode is fully compatible with any real mode program until the program would change the selector registers. That would be especially problematic if the program's code would be located above 1MB.
I hope that clears things up.
Btw. to access RAM above 1MB you had to switch on something called A20 Gate. That's a collection from a very fast AND circuits one of its inputs connected to the Address Bus of the CPU and the other ones connected to an unused output of the keyboard controller on the mother board. I know this last sentence sounds weird but the A20 Gate is also a weird circuit. The HIMEM.SYS would turn the A20 Gate on when it was loaded. Thus, enablig the so called HMA where you could place both data and code and you could actually execute code from there. You could ask DOS to do that by DOS = HIGH, DEVICEHIGH=, LOADHIGH or LH instructions.
According to the Intel's documentation the Virtual 8086 mode checks for 64kB segment limits and it states that you can turn this behavior off, but the how is not documented.
So it's like you changed a segment register via LOADALL instead of LDS/LES and it retained its base address even if it pointed above 1MB because it was kind of forgotten. That sounds like a real way to address the entire address space but still required updating the segment register when you ran out of the actual 64k offset limit.
I hope I understand now. Still, it's very far from the very convenient 386 flat real mode with its up to 4G limits and 32-bit offsets.
Exactly.
When a 30 years 386 can address more ram than your 2010 intel atom....
I noticed that too. He sometimes says gigabyte when he means to say megabyte.
@@TravisFabel nah, gigabyte is correct
@@TravisFabel The 386 could adress up to 4GB. As in 4096MB. But I doubt the bios or the motherboards that the 386 was delivered with could come close to supporting that.
Geir Eivind Mork it is the memory controller that recognizes a certain number of simm’s having dram chips with specific row and column address pins. In first and second generation pentium era, 1995, the normal memory controller recognized 4 simms (some 8?) and did work with 16 mb Simms. It had a provision for 64mb , but did not work with the dram chip arrangement. There were special controllers for multi processor systems for 1 gb
I love that you don't just give the history, but also describe it and how it compares, or in this case applies, to modern computers. Came to learn about DOS history and learnt about a feature of modern computing as well!
The proper crazy part is that every x86 cpu, including modern current day core i7 cpus start up in Real Mode. So your fancy gaming machine first powers on thinking it is a multi gigahertz 8086 about to run DOS. Fortunately for the sake of humanity the UEFI or the OS switches it into protected mode so the modern world can function.
So sit for a moment and imagine a world where we still used DOS on our computers, and conventional memory was still a relevant concept. I imagine himem would take a while to count 8 gig of ram.
It's a thought which fills me with warmth whenever I turn my PC on.
I forget what the last machines actually able to boot real mode DOS were - I know the early Athlon64s and Core 2 Duos could. Any 64-bit chip with a BIOS rather than UEFI, IIRC.
Of course, actually booting DOS on the metal became mostly useless after ISA slots went away, but hey, it's there. The last few things it was used for - firmware updates - now usually use some species of Unix kernel to do their thing.
It's more a feature of the BIOS/motherboard firmware than the CPU itself. Most EFI implementations support legacy boot (which, as far as I know, still lets you boot real mode DOS) through a piece of software that emulates BIOS and dumps the CPU in real mode.
And, of course, you can start up a virtual machine and boot real mode DOS effectively running natively on the CPU still.
such a world would be awesome, I wish microsoft kept the "DOS + GUI" model instead of switching to NT!! :D hahahaha. if they wanted they could make a DOS capable of adressing big ram, using ntfs or a "fat64" and everything needed today.
I actually ran msdos and windows 3.1 in my i7 4500u and 8gigs of ram. But it couldnt adress that so i got down to 4gb and it didnt recognize all the ram but didnt crash.
I played wolfenstein with the pcspeaker.
It was cool
Now I finally understand what extended mode is after all these years. Thanks!!
Extended RAM and Protected Mode ;)... not extended mode ;)
The error "general protection fault" suddenly means a lot more now...
I preffered the Amiga computer's error: "Guru Meditation Error" ;)
He he, or in linux terms Something like Page Fault
God, I learned to program on an XT but wanted a 386 or 486 so much when i read about protected mode. I honestly remeber thinking no one could ever use 4gb of ram, 32 bit address space would be as big as it would ever be.
I wrote an attempt at multi threading by having the timer interrupt push some registers onto the stack and then switch to another sub routine, run it a bit and back again. The "time slice" had to be in seconds, as I remember it, because the XT was so slow.
I had two "threads" which just output a 1 or 2 to the screen continuously to show they were active and when one day I got it to run for about 30 seconds before crashing I felt like a fucking genius.
Oh, good times. Now the only programming I do is little VBA macro code to automate stuff at work.
Great vids BTW. Reminds me of happy times as a teeenager.
Peter Quint the toll on humanity in wasted productive time from terminated apps has stood unrivaled as well....
If it crashed, then most likely you had a stack overflow somewhere. I think it's an imbalance push and pop, because 1/18.2 second is more than enough time for 8088 to push and pop the registers several thousand times if not more.
Very cool video indeed! I was always confused by all these different modes, but this video cleared it up for me and now I know a little bit more about vintage computers. I love these series! Please keep making more!
Thank you! Happy to help... and yes, I fully intend to!
LOL! the suicidal cpu - She cannae take any more, Captain. She's gonna blow ...
Thanks for this great explanation! All those times I did that protected mode thing on my old 386 I had no idea what it really did. All I knew was that it enabled use of the rest of the memory. lol
After some game failed to start I figured out it runs with an another version of DOS/4GW. So I started to collect them and a few other DOS Extenders and several libraries (like sound). They've came handy with my demo mania.
it is incorrect that the requirement of asking (allocate) memory from the O.S. is unknown. the DOS has a special "int" function (21h) that serve this function. It does allocate a specified block size of memory and returns a pointer to it.
I already knew most of this stuff before coming to this video but I just wanted to say this was a really nice and well put together summary. I liked it a lot.
You should cover things like "Unreal Mode" sometime.
Thanks for clearing this up. Was taught this in school in 95, when I was at a tech college. I had simply forgotten the basic's of this knowledge. Good video. Thanks.
This video feels like it stops after the intro. I need MORE!
The 80186/80188 processors were used quite a bit for embedded systems as these processors had a number of peripherals built in.
When I was in school in early 90's in a small rural school in Finland, we had (already then) ancient PC's with 80186 processors made by Nokia. I hadn't seen those CPU's used anywhere else and never understood why they were used on those computers (called Nokia MikroMikko [something]). But now I'm thinking it could have been that Nokia had other uses for those CPU's and wanted to use same components in multiple products. The PC configurations were odd also in other ways, in hindsight kind of like lots of leftovers had been used in making them. (To be clear, the computers probably were OK by performance when they were sold. The school just kept the computers way over their age.)
Back then Nokia made toilet paper, paper towels, tyres for cars as well as for heavy machinery, rubber boots, and various electronics for consumer and industrial use. Later Nokia ditched the other businesses to concentrate on mobile technology, which went well until competitors from Asia got going with cheaper prices, after which Nokia tried with Windows Phones... Anyway, the earlier ditched businesses still seem to be running fine by other names as independent companies. I guess things just don't always go as expected.
What a perfect explanation. I never fully understood this concept until now, thank you!!
Actually memory extenders on 286 used the LOADALL instruction to access memory from himem and copy it to lomem which didnt involve entering protected mode at all. Dos apps also DID request RAM from the OS when allocating RAM. Remmeber TSRs? Dos apps werent necessarily the only ones in memory. There had to be a way to protect RAM even in DOS it just couldnt be enforced. I actually wrote a complete multitasker for DOS when i was a kid which rivaled DesqView. Toughest coding job i have had to this day! :)
I remember using the Watcom C++ compiler. It was just hello world, I hit compile, ran it, and I saw the DOS/4GW banner. It was that easy to have in a program
Yes, but that brings up the question: why would someone assume it to be harder :)?
The mean reason for the extenders was that you needed to fiddle about with changing some of the interrupt stuff when you switched from real mode to protected mode. Real mode and protected mode interrupts are a little bit different. For example if you where running dos and you needed to go to protected mode but wanted to still use the gfx card bios interrupts you needed different code. Dos4gw had that code and was able to do the conversions for you. This is from memory and some of what I'm saying might be slightly wrong. The dos4gw code also had the page file stuff built into it as well. It was rather slow on a 386/486 but was possible.
Desqview was fairly awesome back then as well. The old dosshell was ok in a pinch.
I remember reading about 2 different methods of DOS access to extended memory: DPMI (DOS Protected Mode Interface), which was compatible with being run in a virtual DOS machine on OS/2 2.x; and VCPI (Virtual Control Program Interface?), which wasn't.
Great video! I was just reading about this subject and trying to make sense of it and your video cleared it all up! Thanks!
Best explanation of real vs protected mode that I had encountered.
good but this topic deserves a mega'byte size video
I see what you did there. I like it.
kek
But those games really weren't using the memory protection, and systems like Amiga OS, Atari ST and Macintosh System 7 were running multitasking desktop window systems quite happily on 68K processors without a hardware protected memory management component. (the LC, and EC 020 and 030 processors, as well as base 68000 / 68010)
I say "quite happily", but by that I mean Bombs and Guru Meditation were still less common than the dreaded BSOD of any version of Windows still running under a DOS extender. (EMM386.SYS, in most cases, though you'd get better traction from 386MAX, QEMM or DR-DOS EMM386.EXE) I also say "multi-tasking", when in actual fact the Atari ST/TT and Macintosh were actually "task switching" OS, supporting scheduling and true multi-tasking only co-operatively, and _only_ for "desk accessories", and not full applications.
That still leaves the Amiga, which really was pre-emptively multi-tasking, so the _only_ caveat that I have to make _there_ is that the PAD (Paula, Agnes and Denise) custom chipset (specifically Denise, in this case, IMS) had "memory management" and "thread management" as a core functionality, extending the capability of the main processor. But she could still only control, and report upon what was going on inside the "chip RAM", because she didn't support the full address range of even a basic 68000 processor.
(RISC OS, on the Archimedes computers _was_ always pre-emptive multi-tasking, even before it got a desktop GUI in RISC OS 2, but I believe even the original ARM 1 processor had a memory manager ... I _think_, but I didn't get to it until RISC OS 3, and never managed to crash the MMU, even writing GUI code in assembler, so I'm not 100% sure on that history)
*Key terms*: (for students) _Pre-emptive_ multi-tasking is when the OS dishes out slices of processor time to processes, potentially prioritising one process over another, in response to hardware interrupts and set triggers for "real-time" reaction. _Co-operative_ multi-tasking is when each task does what it needs to do, and then executes an API to tell the OS that it can let another task do some work now. A bit like when you have a camp fire meeting, and pass a stick around to decide who can speak, but the person holding the stick doesn't have to give it up until they're done talking.
The PAD chipset had no such capabilities. The PAD chipset could address the first 512KB to 2MB of "CHIP" RAM as a flat address space, overlapping the 68K's address space, allowing the CPU and Agnus chips equal access to graphics data. The Amiga 1000, 500, 2000, and 2500 literally had *no* memory protection capabilities on stock configurations. You literally needed to install a 68020 or better accelerator card in order to even entertain the *thought* of using an MMU (which most people left the MMU sockets empty).
Thread management was exclusively the domain of exec.library. It's a purely software construct (and still is today even on the most heavily memory protected systems). The chipset had nothing to do with it. Memory management was also the domain of exec.library, again without any help from the surrounding I/O hardware. Exec maintained a free list of unallocated blocks of memory, some of which were identified with certain flags (c.f. MEMF_CHIP and MEMF_FAST, etc.). When you invoked AllocMem(), you always told it which kind of memory to allocate the second parameter (e.g., xyz = (BPTR)AllocMem(1024, MEMF_CHIP | MEMF_PUBLIC)). Whenever you installed memory cards, expansion.library would interrogate the autoconfig ROMs on the boards for memory regions and their flags, which always had MEMF_FAST set by the way, and would amend the kernel's free list during autoconfig time (when the screen is grey during cold boot).
Correct. I programmed against it as such, treating it as a black box that just worked.
Also, I've never reversed exec.library to find out what it's _actually_ doing. What I _do_ know is that early x86 Amiga emulators for DOS struggled to emulate the PAD accurately enough, in a timely manner, for exec.library not to fall over. I've read some of the AROS developers lamenting the lack of hardware PAD to re-create exec.library, and I know there were 030, and 040 software exec.libraries I used to use which documented moving "memory management" off the PAD, and on to the MMU in the CPU. IMS, what they said was that the chipset was used to help swap out registers between threads, and to help detect illegal memory operations. However, without a proper MMU, it still couldn't stop the CPU _before_ it corrupted other space, (illegal operation) it could only detect that it had done it during the next thread cycle and halt at that point.
Something like that. It meant that multitasking on a 68000 / EC0x0 processor was more efficient on an Amiga than, for example, an ST, or Mac, but didn't mean it was any less prone to requiring you to reboot. Of course, the default OS on ST and Mac didn't have multi-threading, and only really switched tasks in response to user requests, but that didn't mean you couldn't run a "proper" multi-tasking OS on them. ;) (I had an ST too, and used an Mac LC20? at work)
I used a full 040 board in a A1200, (it died) and have a full 030 in my A4000. I _really_ appreciated the yellow gurus which returned to the desktop killing off the offending app without forcing a soft reboot, but they didn't really kick in until I replaced the exec.library with the appropriate software patch version, and became better with some of the 3rd party versions which would convert the yellow guru into a nice reqtools / MUI dialog. The later, with a proper thread mini-dump! :D Very handy.
There is also more to protected mode than just access to memory. Due to the way the segment registers turn into selectors instead and being able to access a 4gb chunk of memory with just an offset register instead of having to read a 64k block then move the segment forward and repeat, this enabled much higher performance and simpler code. (I am.talking 386+ protected mode here)
Thanks, I've wanted to know more about DOS/4WG for a couple days. I didn't know it was such a big deal
You are more than welcome!
ahhh the old days of using qemm 386 squuezing out every last bit of memory.. good times :o)
I'll come onto that in another episode!
qemm was the shit.
I'd love to see you explain other memory modes!
Thank god those days are over. When CPU changing the running mode means there wasn't any debuggers on the market that can be used for tracing the system code. So writing code that puts processor into protected mode meant many days of assembly code reviewing - this was the only way to debug at the time until affordable ICE chips came out on the market. All that changed with DOS extenders. Using DOS4GW (Tenberrys Software's DOS extender for Watcom compiler) assume that once processor is in protected mode, the application stays in protected mode and it allowed stepping through the code. All dos interrupt services were done in virtual 86 mode. This worked beautifully as long as the program stayed in protected mode. Before DOS extenders, we used Expanded Memory Manager device drivers. Basically memory is written to a small mapping zone, then you ask device driver to go into protected mode and copy the 64K chunk (Divided into 4 banks at the time) to extended memory (memory above 1MB). To address the content you would have to issue swap (copy from extended memory to your zone) before accessing the memory - that was pain in the butt but it did not last long.
One thing I've seen in reference to 64-bit computing is "long mode". Is that like protected mode but 64-bit? Or is there more to it?
Basically yeah i think.
That is the 64-bit flat mode of the 64-bit processor, yes. It also does not have segments (except FS and GS).
My first job was at Elite Systems and we used Watcom C and DOS 4GW before moving to DirectX. Interesting times :)
As always really enjoyed your video!
Important to note that the 286's extended memory of 16MB of address space was only accessible via 64KB segments, just like the 8088/8086. Flat memory didn't arrive to the x86 world until the 386.
Wait, there was a ONE-8-6!?
Also though, great vid. You explained away a lot of the gibberish from the boot screens of my youth. Things I didn't realize I wanted to know about until I just did.
yup, the 80186, intro'd in 1982 and would have be the replacement of the 8086 in PC's. However (and Wiki-quote here) "because its integrated hardware was incompatible with the hardware used in the original IBM PC, the 80286 was used as the successor instead in the IBM PC/AT."
And;
"The Intel 80186 is intended to be embedded in electronic devices that are not primarily computers. For example, its offshoot, Intel 80188 was embedded inside the Intel 14.4EX modem released in 1991. The 16 MHz processor was used to perform complex algorithms needed for forward error correction, Trellis coded modulation, and echo cancellation in the modem.
In May 2006, Intel announced that production of the 186 would cease at the end of September 2007.[4] Pin- and instruction-compatible replacements might still be manufactured by various third party sources.[5]"
en.wikipedia.org/wiki/Intel_80186
i think those weren't that popular, however the "microcontroller" version of it was far more used. i had at least 4 or 5 PCBs of random peripherals (ISA cards, tape drives, scanners, and so on) that uses the 80C186.
Yes, but never used for PCs (or any micro computer that I remember), it was intended as a microcontroller.
Yup! I believe a few computers made use of it, and it was broadly similar to the 8086. However there were incompatibilities with the existing chipset and the machines incorporating it were rather niche.
Great informative video!
Altough I am a little bit confused now. DOS 6 has these drivers called HIMEM.SYS and EMM386.EXE that lets you use memory above 1024K (and between 640K and 1024K). Is this for real mode only then?
Himem.sys exploits a bug originally created in 286 processors which mapped the first 64kb of extended memory to it's 20th address line. You can therefore shift (or swap) parts of conventional memory into this High Memory Area to alleviate the 640Kb memory constraints, but you can't execute code within it like you'd be able to in protected mode. EMM386 emulates an earlier expanded memory standard (EMS) using extended memory (XMS), and allows you to load drivers from conventional memory into a high memory area between 640k and 1024k by mapping this memory... I discuss EMS in this video th-cam.com/video/zUvsER6l56Q/w-d-xo.html
Those drivers were also in DOS 5 and I believe Windows 3.1 also had updated versions of them on the installation disks.
Fascinating. Thanks for putting this together. :)
Already knew this but I watched it anyway just because I enjoy your videos.
Early Intel cpu modes were a pain in the butt to program for. Motorola and others had the right idea. The 6502 series, for example, was the king of efficient and logical code organization and execution. Assembler for that chip just makes a lot more sense with no worry of program and data segments, protected or real modes, etc. I would love to have seen a progression of the 6502 to a 32 bit data and address bus with the same level of code efficiency, but alas, that didn't happen.
I remember operating UNIX System V for 80286. There was also a Microsoft-licensed version of UNIX called Xenix that was made for the 80286. They were the precursor of Windows for Workgroups in a sense, because Windows could not yet run networked applications - UNIX and Xenix could.
DOS/4GW is memorable. If application using it also used sound crashed often it resulted in hellish noise loop from your sound card at max volume.
I remember that in 286, the protected mode was a one way ticket. You can get there but you cannot return to real mode, except if you reboot the system.
Ahh~ the days of running DOS and trying to get things such as the EMS and XMS running.
Never will I forget what pain in the butt this was.
It is essential for any multitasking OS to have a protected memory mode? Well AmigaDOS managed to multitask without one quite successfully. Admittedly it did mean any badly written software could bring the whole system down like a house of cards, and developers used Enforcer on 68030 onwards to debug their software so it played nicely. Also I seem to remember that the method of pre-emptive multitasking the Amiga used required protected mode to be switched off to work properly. As it was developed from TripOS onto chips without a protected mode it's bot surprising that protected mode would have interfered with its workings. They probably should have developed memory management in software to get around the issue.
Didn't someone develop a version of DOS for the PC which could multitask? How did that work?
I like learning so much.
There are still hardware "experts" out there who claim that DOS is more than capable of accessing memory beyond 1 MB in Real Mode and defend their claims wildly. Dealing with these people can be... annoying, to say the least. :P
Should ask them to provide a demonstration.
yes, that is correct, it is called HIMEM.SYS which allow by through an API to access that higher memory. And where it maps the current page in view?, in the address space of the memory hole, IIRC 740K-1024KB addresses, well that is left after the hardware takes its bytes..
Wait, you're saying that I can no longer access almost 64 kilobyte of overhang above the first megabyte in real mode? How cruel of you!
the standard is 0 up to 720KB (720KB not includes) is RAM, upper from that is EMPTY space addresable to ISA cards, so, the video card video memory is accesable by that memory hole, and others cards too.... but including having all FULL of card, there is still an unused address range, that is taken by HIMEM.SYS...
+flyguille Yes, BUT, HIMEM.SYS achieves this affect by temporarily switching the CPU into protected mode then back again, which creates the illusion that Real Mode can itself access memory beyond 1 MB when it can't. :P
Very interesting, thanks for this and I'm looking forward to anymore like it.
You explain content very well and in depth but it would be better if u speak a little slowly !
I don't know if you're still running this channel as I've asked quite a few questions but here goes another one...Would an extra processor for the protected memory help run several programs at once on say a...286? Can they use a virtual core today to speed up the protected memory while running say...Office 365?
Not sure if it is just me, but I do not understand what you are asking and why? What are you wanting to do with this hyperthetical modified 286 and why?
@@ksp1278
The question was about running a much faster processor than the 8088 in protected mode. I want to know if it's possible to say emulate a 286 today entirely on a virtual core? I want to know how far I can push it before the whole thing breaks.
@@Sinn0100 I am sure that modern PCs are fast enough to be able to emulate a 286. In fact DOSbox is a kind of emulator for DOS software such as that designed to run on hardware like a 286. But I don't think that's what you are asking is it?
@@ksp1278
No but that's okay man! Thank you for the awesome response. Too be honest, I'm quite sure what I want either. I'm now infatuated with recreating my old cloned 486DX2 that I had as a kid. I have it almost completely together. Finally, I can play Doom on a....oh wait a minute, everything runs Doom now. ;)
@@Sinn0100 I am similarly trying to create some PCs to relive my childhood. In my case my first DOS games were Prince of Persia, Wolfenstein 3D, Duke Nukem 1 and Wing Commander 1 up through to Quake, Duke Nukem 3D and Privateer 2. I am creating 2 PCs to run those games. Both PCs are made from laptop motherboards. 1 is a Pentium MMX 166Mhz. That can be slowed to around the speed of a 386 by using setmul utility. For late 90s DOS games I have a 400Mhz Pentium III laptop motherboard. The main problem with laptops is lack of CD audio in DOS (They laptops I chose DO have soundblaster Pro compatability so can play midi and standard audio). I am yet to work out a solution to that CD audio problem. For Windows 95/98 games I am using a 2.0Ghz Pentium M based laptop motherboard with Radeon 9000 graphics. I am using laptop motherboards due to space constraints. My wife does not approve of me collecting old tech! Lol. So I have to keep it hidden. Haha.
if I recall correctly EMS don't need protected mode: there's facilities in the DOS (interrupts) to page in and out ofr XMS/EMS.
So technically the barrier of 1024kB was not really a limit :)
It depends on the type of EMS or rather where you're getting that EMS from. As I'm sure you probably know, EMS stands fro Expanded memory system. Way back in the beginning, when you had only the 8088/8086 processors, which could only run in real mode and only had a 1MB physical address space, the only way to have expanded memory was an add-in ISA card that had additional memory on it. That memory was bank switched and was mapped into the existing address space through a small window. You accessed different banks of the memory by writing a number to a port which switched which bank was mapped into the window. When 386 processors came out, Dos came with EMM386. EMM386 was a device driver that loaded into memory and emulated all of this and enabled you to use extended memory as EMS. What's really happening there is EMM386 is using protected mode and doing it all for you in the background. In fact the "protection" of protected mode is what enabled EMM386 to do this. Protected mode didn't just protect memory access, it also protected input output ports. So, in protected mode if a program attempts to directly access an input output port it generate an exception or a protection fault just as it does when a program attempt to access a memory location outside of it's space. An exception is handled like an interrupt in that there is a pointer in the interrupt vector table that points to a location in memory where code that handles that exception exists and the processor immediately jumps to that location and executes that code. So, in the case of EMM386 that exception handler would be triggered whenever a program attempted to use expanded memory and EMM386 would then take over and handle it accordingly. Anyway, if you use EMM386 for EMS, technicaly you are using protected more or at least EMM386 is using it to emulate it.
@@stefanl5183 thanks for making my point. Protected mode is not a pre-requisite to EMS.
@@unperrier5998 "Protected mode is not a pre-requisite to EMS"
No, it's not a "pre-requiste" if you have an old 8 bit ISA card sitting on an slow 8 Mhz ISA bus with whole bunch of slow memory chips on it which are mapped into a small window in upper memory. Those cards were only 8 bit 8MHz ISA cards because they were made for the XT which only had an 8 bit 8mhz bus. When the 286 and 386 were introduced those cards were obsolete and nobody in their right mind would ever use one in anything but an XT. Instead they used software like EMM386 which emulated it, because it was much faster, and for that protected mode was a "pre-requisite".
Nicely explained
Still waiting for a fairly modern browser for DOS using a DOS extender. Modern DOS Box-X uses a free DOS Extender (HX-DOS) for a port to DOS. Yes emulating DOS in a DOS OS :-)
It is not true that DOS programs did not ask memory from the system, there was dedicated API for that !!!
Obviously. The operating system is what controls everything in the background.
But DOS-applications did not expect to share the totalt memory with any other program.
Many DOS-programs were written to use specific hardcoded addresses in memory. That will never work in a multitasking system.
QEMM-386 FTW
Love the KOTOR reference
why we had both XMS and EMS listed when you typed "mem". why were both of this methods used and which one is newer and better standard?
Funny you show Windows 3.1 while discussing protected mode... Windows 3.1 has incredibly bad memory separation between processes. As in... absolutely none. Memory separation between processes didn't happen until Windows went 32-bit.
I was told, yet I couldn't verify it, that IBM OS/2 made use of the 286 protected mode and tweaked it a lot, to be able to return to real mode without a complete reset of the 80286 chip. Anyhow, all theses tweaks weights a lot on performance, wich can explain a bit why OS/2 failed where Windows NT succeeded.
1:21 That's not entirely correct, if you have a 286 executing code at FFFFF, it will continue on to 100000 rather than rolling over to 00000, unless you're on a PC (where the A20 gate applies)
When moving from protected mode to real mode the CPU actually does reset but the memory does not. It just does it so fast that you can't really tell.
You ignored the memory technology fight, extended vs. expanded,
80286 protected mode was widely used by the Intel-compatible Unix operating systems of that era.
You are not a lazy software reviewer
These are one of the reasons why we have MS-DOS bootdisks.
Never mind all this hardware talk, that's leodard's mom from bi bang theory at around 4:11. Christine baranski and there's nowhere she's credited for this appearance. Not on her imdb, wiki, anywhere! Also my first computer was a Vic20 as advetised by captain kirk himself! I'm that old.
Borgwar! Played that when I was a kid. :D
Ah Rise of the Triad!!! Our entire engineering team ended up playing after work until something like 10pm when the owner's wife called the cops on us because she heard screaming in the building. I was the lucky one to have the cop bang on my office window with his batton. Those were the days.
Back in my 80286 days, dos4gw meant: this game only runs from 386
Cool Video. Computer Education. I like it :-)
did i see a Star Trek Game in the video?!
I wish there was a plugin to remove background music from videos.
Can anyone tell me what that 'greenscreen' interface at around 2:07 is, please? It looks so familiar but I can't put my finger on it *gah*!
lol, think I answered my own question with google reverse image search - rhodesmill.org/brandon/notes/unixpc/transfer.html I'm pretty sure I had to use this interface at a workplace in the 90's!
I sure do like 'em protected modes.
Carefully mispronounced to make people understand it's not meant to offend anyone.
The immportant thing dos extenders did was allowing the program to communicate with dos. not going to be able to do much if the program can't read files access the disk becaause protected mode broke things
3:26 Technically, not *essential*.. Just a jolly good idea, since it enables the OS to terminate malfunctioning software instead of potentially allowing them to take down the entire system.
I remember have to load a sys file in DOS to access more memory
Most interesting.
thank you so much
You are welcome. Thanks for your comment!
aarrgghh - 80286 selectors and call gates and no-exec flags on a selector and swapped-out whose size on the selector up to 64Ki... so glad they scrapped most of the old protected mode in 80386 and made a page system instead
I used to have a program for my still video capture card.
No os pure 286 protected mode.
Virtual 8086 on the 386 doesn't exist anymore in 64bit cpu.
It's now protected mode (32bit) and Longmode (64bit).
Explanation of DOS 4GW at 4:50
how to turn off dos?
Windows NT.
Third ..... another great video, keep them coming
No prizes for third. Apologies.
And this is the legacy that 40 years later has crippled every x86 processor and the entire general computer market. Intel and AMD need to totally dump backwards compatibility and start over from Day One designing an entirely new processor, that can truly take advantage of the advances in physical CPU manufacturing...
I still have nightmares about ultima 8. I needed 8megs of ram free and I had one partially bad memory chip, so I only had about 8000k total. It drove me crazy that 8000k wasn't 8192k so even with QEMM, bootdisks, etc. etc. I couldn't free up enough memory for Ultima 8. I never played it but I had dreams of how awesome it would have been... Sigh.
[3:43] The guy playing Charlie Chaplain looks like Captain Disillusion!
You are wrong about the DOS memory model. There was a call to DOS to allocate or free memory.
mov ah,048h ; function number
mov bx,1 ; how many 16 byte chunks
int 21h
was how you asked for memory. ax would be the memory segment for the new allocation.
If you didn't do this, DOS could lock up when your program ended.
Yeah but if you wanted to could make a pointer to any address in the memory space and read or write there. Everyone overwrote the damn interrupt table as I remember it.
In protected mode you couldn't do that unless the operating system said you could.
Peter Quint:
The mistake in C of making the "null pointer" zero was what lead to that bug mostly. If you dereferenced a null pointer, you wrote to low memory. Badly written code was about as common in those days as today.
I wrote a lot of code in those days. One that I thought was quite clever was a little TSR that allowed the printer port inputs to be used as contact closures that made switches appear to type stuff. Among the uses was to make a foot-switch page down through the instructions while you did something with your hands.
I also wrote a multitasking addition to DOS with "multi" being two. It allowed one operation to run without user interaction while the user interface ran doing other stuff.
Protected mode... Aka 32 bit mode, more or less. I think... From memory.
In any event some aspects of it are similar to what you see with the 65816 which is compatible with the 6502.
It starts up in a mode where it behaves identically to the older processor until you issue an appropriate set of instructions to switch it.
The x86 CPU is similar, in that it starts of in a mode that is basically equivalent in behaviour to the original 8086...
Even modern processsors like a core i7 still do this.
Backwards compatibility does weird things huh.
Anyway, enough of my random stuff, go watch the video and see a probably much better explanation. (if nothing else because it was probably actually researched and scripted, rather than my off the cuff remark going wholly from memory... XD)
Free access of all hardware components vs virtual concentration camp, who is the big boss of your system?
as i watch this im eating oizza.. while waiting for pizza to be delivered. what is my life
Nirvana?
One mode to rule them all and in the swap-file find them.
What is protected mode? Those god damn SIGSEGVs that happen when debugging a new program for the first quite a few times XD
(Don't take this too seriously though XD)
Totally annoying thing when I have used Rhide. But Pascal was even worse, you will declare an array of 20 and you will end asking for the 20K position because a bug. Sometimes Pascal would drop into DOS badly, no message, no nothing, probably lost all the changes. Sometimes crashed the whole system to the point it self reboot. With protected mode the IDE was able to catch this things and stop them to avoid problems. But the first steps on it, with this criptic SIG events, pain in the ass to trace where the hole was. But ... sometimes DOS itself terminated the IDE (i.e. the debug sesion) before the IDE was able to catch the issue. Once you were quick out, no clues at all. The old time, long hours in the IBM PS2 with the clunky keyboard. What a tank.
XD When using C#, SIGSEGV would trigger an exception, but in C++, it's like, WAT, the program just crashed and I have no idea where it crashes...
I'm not that sure how PASCAL works, as I only used that for like, well, 3 days I guess, not to mention there's already no need to use that language for anything. But, what kind of bug would result in accessing the 20,000th element in a 20 element array? I can understand having "off by one" bug, accessing of NULL pointer, and use a pointer that's not initialized, but, why trying to ask for the 20K?
Also, that's exactly why you should always save before compile, I guess XD
LOL, just imagine it is you first try at programming, and your end condition faillled or never existed, so you keep reading and writting far from the boundary. Borland Pascal was used as a learning language, more or less like BASIC, it was pure DOS thing.
For this enviroment, pointers were UNKNOWN, but you could trash the memory to the hell and the IDE was blind about that. It just keep going until something at DOS level exploded. It easy to have bugs like that when you are trying programming for the first time and the IDE is SO OLD that doesnt care about memory. Also, pascal input routines were total garbage. C input scanf is WAY more secure and consistent. Pascal crashed if you type a letter when a number was expected. It was up to the programmer to validate input at that level. Of course C# is another world. You cant even think in pointers anymore, is the way it works. Also, Visual Studio got so SMART through the years that is even catching small bugs while you are writting, FAR from a non declared or initialized var, it catch unreachable code, lack of return paths. Im using 2010 PRO edition, cant imagine the last edition. More like the IDE helps you to programming. But the paradigm changed, before, you write functions. Today you still do, but .NET framework will do most of the "old days" work for you with tons of methods so are now focused in more complex apps that integrate DB ... WEB etc. Of course never got a kick off from Visual Studio. It just halts at the point and let you know you mistake. I wont close suddenly. But VB6 ... it was more like PASCAL. Example, just write code used a var that is not declared .. NO PROBLEM !!! it will run anyways and eventualy when this part is reached just crash or get unexpected results. But at least will warn about walking outside boundaries. Pascal ... WONT ... just try it for curiosity. If you wanted to trash DOS until it reboots itself, no probs, you could. Not clear to me but like it was not using protected mode. As I told, the PC was the venerable IBM PS2, 4MB I think, with the IBM C O L O R monitor (wow) running PCDOS from IBM.
Back in DOS era, when you are running a program it takes ALL of the resources so, it won't quite be an issue if you crash DOS somehow. And if the input routine can cause crashes I'd say just switch to another compiler. But, I don't think there's anything else available besides Borland Pascal. I ended up didn't get too far into that language simply because it looks weird and that's it. In fact, the only two things I remember about it are, it uses "begin" and "end" for scoping, and ":=" for setting value.
C# still has pointers, just, it's not working completely like in native C++ (C++/CLI is a thing so have to say "native here). You can only use a pointer when you fix a variable to a native memory area, otherwise .NET assumes that it can move the storing location of that variable without telling anyone, as it manages the accessing of that variable for you.
As for IDE, I'd say that the main reason I prefer C# over other languages is simply, Visual Studio is awesome. And I think that the "IDE helps you program" thing is absolutely reasonable. If I have to do something else every time I do something anyway, why not just ask the IDE to do that for me? Machines never go tired but I will. For standard libraries, well, if there's not one available you mostly would just copy one that somebody wrote a million years ago anyway.
For VB6, I think every expert would tell you to use the god damn "Option Explicit". I mean, why not? Without that, any typo would ruin the whole program and there is absolutely no error to be shown. If any book out there tells people not to use Option Explicit I would instantly hate the author of that book.)
By the way, I'm using VS2015 Community since I'm not working in a big company or something like that.
LOL Borland Pascal was SO WEIRD. But, you know, they insisted it was the right tool. Crazy because I learnt that in 2000 and working in DOS machines was no sense. They told you that it was the best choice to teach programing ... well, not to me. The next curse we moved to C and used RHIDE that is djgpp on Windows. It like a Borland front end using gcc and gdb tools ported to DOS that run in protected mode only.
I started with C# not long ago. I need to work on an ALREADY EXISTENT project and I was mad about not being able to use pointers. Pointers are still there but the code is unsafe and eventually, the power of the .NET framework and all the mechanism that allocates and free memory wont protect this part of code ... Plus, I cant start using pointers when other modules never did, just because tidyness an using an even criteria. So I worked my way, using either byte arrays or strings. Eventually sending or receiving an struct from or to a buffer, a simple thing that only requires a cast it is a torture when pointers are not used. Managed to get thing going with string and byte arrays. Also, I couldnt figure out how to declare structs, I ended creating a class just to hold the data structure .. which ... I dont like. But my boss eventually preferred this approach. It a great tool, powerfull and well used, you type little code. I always look at Stack Overflow for the best approach when doing something, discovering that one or two lines can be enough to solve a nice piece of code. And as you said machine wont get tired, Intellisense is there checking whatever you write is valid or not.
HUY!
William!
Thank you for saying heighty heighty-height, sincerely. 😜