we need more programming discussion [Archive]

Mike Chambers

October 10th, 2006, 10:55 AM

chuckcmagee

October 10th, 2006, 11:11 AM

All my "programming" of late has been fixing bugs with downloaded open source operating system packages. Finding a missing "include" in a ".c" file, patching this or that for the correct PCI ID, figuring out why the current set of libraries are messed up, etc. I do hours and hours of compiling but it's to rebuild linux kernels, build new modules for my hardware setup, or compiling "portage" packages in Gentoo or FreeBSD. I haven't done any real "get this project done soon" programming since 1999 and that was always work related.

Mike Chambers

October 10th, 2006, 11:22 AM

yeah i know what you mean, "get this project done soon" programming as you call it.. pretty time consuming. not good if you have a job or a family hehe.

IBMMuseum

October 10th, 2006, 12:22 PM

come on, are mr. brutman and i the only programmers here? can't be! :)

anybody else here working on any cool vintage programming projects? the best thing ppl can do with old machines is write new software that lets them communicate with all the newer services and stuff on the internet. it keeps them somewhat useful!

Not just Internet connectivity, but code to keep up functionality. Typically I play with the (PC) hardware level more, but that gives me the background to understand how the software is working too. Not as much "tinker time" as I would want these days however.

even though i generally program for DOS in quickbasic 4.5, it is still a viable language for old machines. especially when you incorporate ASM.

btw, if anybody is curious how to do that... you would go about it like this: (roughly)

DIM asmStringData AS STRING * howeverlongitis
asmStringData = blahblahblah pre-compiled ASM code here, make sure you add a RET opcode at the end

DEF SEG
CALL ABSOLUTE (VARPTR(asmStringData))

you can even do some "compiling" within your qb code, for things like pointers to strings or other variable you need to ASM code to use. from my experience, the string containing the ASM code HAS to be a fixed-length string in QB's memory otherwise call absolute kinda goes "WTF?" and nothing tends to happen.

if you wanna just try this out for kicks, load up a pre-existing .BIN file (compiled code) into that asm string and call it :)

it's great it combines the simplicity of QB coding with the power and speed of ASM for parts where the QB code for the same thing would otherwise take forever on an 8088 or 286 or what have you
I am self-taught on x86 assembler. Also I like BASICs back even to the ROM level. Linking them up is a little bit harder than QuickBASIC.

The projects I am looking at are specifically tied to microchannel PS/2s (Models 50 to 95), so someone without such a model would not be able to give much input. But generally I would welcome any help, even to the level of getting them set up with a microchannel system. A few (small) things I have done are at http://www.IBMMuseum.com/Routines/ (ask questions if you need).

For those out there that don't know, microchannel was one of the first implementations of "Plug & Play". The adapters required description files (or "ADF"s) to be initialized by the system for the resources they used. Really it is fascinating what could have been on the PC forefront if things had been different (also I welcome people to visit the comp.sys.ibm.ps2.hardware newsgroup).

At the basic microchannel PC level the systems started with VGA, usually a mouse, and BASIC built into ROM (just like the original PC). An idea of mine was to replace the specific "Reference Diskettes" with a generic version for several PS/2s, using the VGA & mouse capabilities in their setup programs. And when I talk about the possibility of the tokenized BASIC op codes being on diskette to save space, being used by the ROM interpreter it gets real interesting!

IBMMuseum

October 10th, 2006, 12:27 PM

yeah i know what you mean, "get this project done soon" programming as you call it.. pretty time consuming. not good if you have a job or a family hehe.
"Job" and "family" are not mutually exclusive words either. "Honey Do"s at home, and tasks that aren't put that lightly at work. I would become a better programmer if a won the lottery & didn't have to work to support my family.

Mike Chambers

October 10th, 2006, 12:40 PM

Not just Internet connectivity, but code to keep up functionality. Typically I play with the (PC) hardware level more, but that gives me the background to understand how the software is working too. Not as much "tinker time" as I would want these days however.

I am self-taught on x86 assembler. Also I like BASICs back even to the ROM level. Linking them up is a little bit harder than QuickBASIC.

The projects I am looking at are specifically tied to microchannel PS/2s (Models 50 to 95), so someone without such a model would not be able to give much input. But generally I would welcome any help, even to the level of getting them set up with a microchannel system. A few (small) things I have done are at http://www.IBMMuseum.com/Routines/ (ask questions if you need).

For those out there that don't know, microchannel was one of the first implementations of "Plug & Play". The adapters required description files (or "ADF"s) to be initialized by the system for the resources they used. Really it is fascinating what could have been on the PC forefront if things had been different (also I welcome people to visit the comp.sys.ibm.ps2.hardware newsgroup).

At the basic microchannel PC level the systems started with VGA, usually a mouse, and BASIC built into ROM (just like the original PC). An idea of mine was to replace the specific "Reference Diskettes" with a generic version for several PS/2s, using the VGA & mouse capabilities in their setup programs. And when I talk about the possibility of the tokenized BASIC op codes being on diskette to save space, being used by the ROM interpreter it gets real interesting!

i dont have any original PS2 machines, but i will take a look at your projects! sounds interesting.

mostly i have been using ASM within qb to write text data directly to the screen, for example in the IRC client i've been programming. PRINT works fine usually, but when you want to add color using attribute bytes to make the UI look sexier(plus being able to support mIRC color codes)... alternating between PRINT and COLOR commands for every byte in the string takes FOREVER on anything less than a 386. i could use POKE to write directly into the B800 segment, using a FOR loop to go through the string's data but thats not much faster due to the FOR loop's overhead. (thank you, microsoft for writing such an efficient interpreter/compiler :rolleyes: )

giving the pointer of a string(already interleaved with the attribute bytes) to a chunk of compiled ASM and having it write it all with MOVs is definately the best way to go... pretty much instant even on an XT.

carlsson

October 10th, 2006, 01:11 PM

Mike Chambers

October 10th, 2006, 01:45 PM

I started on a VIC-20 game (which already has received a lot of anticipating fans, despite it barely is 1% done yet) a week ago, but currently busy with other work so it'll have to wait a while.

I don't do any network programming for vintage computers though, mostly because I don't own any suitable hardware and that's not where my interests lie.

keep us updated on this! i don't have a vic20 (although i'd like to buy one, they're very cheap on ebay) but i do have an emulator. i'd like to try it :)

what type of game is this?

Chris2005

October 10th, 2006, 01:54 PM

"anybody else here working on any cool vintage programming projects?"

a dude on classiccmp announced last night that he's interested in building a Tandy 2000 emulator. Arguably a vintage project (not meant to run on actual vintage hardware), but I might take a look into that whole emulator conundrum just for fun. Can't imagine myself getting too involved right off, but who knows...

"the best thing ppl can do with old machines is write new software that lets them communicate with all the newer services and stuff on the internet. it keeps them somewhat useful!"

Let's agree to disagree. Not at all a bad idea, but I don't believe programming on vintage stuph has to have anything to do with bringing them up to date. What about (and I'm borrowing the term here) an IBM Peecee emulator to run on an actual Tandy 2000 that allows you to pop in *most* any standard peecee ware and watch it run? You could argue that's extending the machines usefulness, but we'd have to spend some time arguing the usefulness of an early 80's DOS machine!

"even though i generally program for DOS in quickbasic 4.5, it is still a viable language for old machines. especially when you incorporate ASM.

btw, if anybody is curious how to do that... you would go about it like this: (roughly)..."

Blah blah blah. NO! The way to do it is POKE individual numerics into memory then transfer control to that point. That's the MAN'S way of incorporating assembler into a BASIC or C proggie. LOL LOL Of course I'm kidding, but it just might be more illustrative of what's going on (fer noobs). Oftentimes, you can't even find assemblers and compilers for some of these things. So yer stuck with either GW-BASIC or an equivalent.
I've thought for some time peeps need to have a place to /store/contribute programming examples, so noobs can cut their teeth.

IBMMuseum

October 10th, 2006, 03:30 PM

What about (and I'm borrowing the term here) an IBM Peecee emulator to run on an actual Tandy 2000 that allows you to pop in *most* any standard peecee ware and watch it run? You could argue that's extending the machines usefulness, but we'd have to spend some time arguing the usefulness of an early 80's DOS machine!
Actually I wrote a couple of programs for DOS that would check if they were running in a Windows DOS box. Why? Because they were banging on the hardware & wouldn't function correctly (and could crash some systems) if run from Windows.

When people start talking about emulators it is usually to run older software (or software from another type of system) on a newer system. With some of the resources that process needs it typically means a very new system. You are probably welcome to talk about it here, but that leaves the concept of vintage computers behind (other than in the virtual sense; if I need to test software for the original PC, I would pull out the original system, which is a good use for a "1980's DOS system").

Chris2005

October 10th, 2006, 03:37 PM

right, an emulator isn't really necessarily positively vintage programming. But when I said emulator I didn't really mean that, but actually a patch of group of patches that would eh intercept calls meant for a real peecee and process them or whatever so that they'd interact with the actual hardware in a positive fashion (i.e. not crash).
The dude who donated some old 2000 stuph including the original "boot code" apparently the bios source code (the 2000's bios was NOT located in firmware like virtually every other pc, but was loaded from disk - just don't say that around Kelly kbysd cuz he'll tell you yer wrong and fall on the ground and swing his feet LOL LOL LOL) was working on just that. I'll have to dig up the e-mails from him and elaborate further. REALLY groovy stuph IMHO. Maybe just something you'd be inclined to like.

michal

October 16th, 2006, 12:46 AM

DIM asmStringData AS STRING
asmStringData = blahblahblah pre-compiled ASM code here, make sure you add a RET opcode at the end

DEF SEG = VARSEG(asmStringData)
CALL ABSOLUTE (SADD(asmStringData))

Right. Even more vintage would be using the PC ROM BASIC instead (as David with his PS/2 code) with the ASM inlines. Having BASIC in ROM is an added benefit of a genuine IBM PC (or PS/2) - too bad IBM didn't update the code so there's the 1981 version in a 1987 computer (with cassette-based commands and CGA graphic modes). But that could be of benefit too - it's brute-forced compatibility :).

A question: how to convert asm mnemonics to the "pre-compiled asm code" string for Basic ? I have a program that does it for Turbo Pascal 3/4 - it's called Inline (put version number here, mine's 2.19), takes a file of assembly mnemonics and outputs a string that can be copied directly into TP code. Is there such a thing for Basic?

If not, I'm gonna have to take a two-step approach with 1. a full-blown assembler compiling to .COM file and 2. a script to convert the output byte by byte, OR modify the Inline TP assembler (it comes with TP source) to output Basic-compatible strings... Loading .COM files is not an option (ROM BASIC does just cassettes...).

Mike Chambers

October 16th, 2006, 01:27 AM

Right. Even more vintage would be using the PC ROM BASIC instead (as David with his PS/2 code) with the ASM inlines. Having BASIC in ROM is an added benefit of a genuine IBM PC (or PS/2) - too bad IBM didn't update the code so there's the 1981 version in a 1987 computer (with cassette-based commands and CGA graphic modes). But that could be of benefit too - it's brute-forced compatibility :).

A question: how to convert asm mnemonics to the "pre-compiled asm code" string for Basic ? I have a program that does it for Turbo Pascal 3/4 - it's called Inline (put version number here, mine's 2.19), takes a file of assembly mnemonics and outputs a string that can be copied directly into TP code. Is there such a thing for Basic?

If not, I'm gonna have to take a two-step approach with 1. a full-blown assembler compiling to .COM file and 2. a script to convert the output byte by byte, OR modify the Inline TP assembler (it comes with TP source) to output Basic-compatible strings... Loading .COM files is not an option (ROM BASIC does just cassettes...).

what i use is emu8086. i compile it as a .bin and it works great :)

Chris2005

October 16th, 2006, 04:26 PM

Mike Chambers

October 16th, 2006, 04:34 PM

Hey Mike, what do you know about console apps/virtual-86 mode, and all that rot? If someone was going to build an emulator, let's say a Tandy 2000 emulator, would the api's and mode available on modern processors make it any easier? I suppose Mike Brutman may want to jump in on this one.

i'm not sure... you mean a windows console box?

i've programmed simple (S*I*M*P*L*E) emulators before, such as one for a college project designed CPU for calucators and ran their supplied BIOS ROM on it... worked just fine. that was like 3 or 4 years ago i cant even remember the name of the CPU.

not as cool as it sounds though... i think there was like 25 or 30 opcodes lol.

mbbrutman

October 16th, 2006, 04:42 PM

The 80386 introduced 'virtual 8086' mode. The host OS sets up memory a memory region which looks like classic flat real mode addressing inside of the virtual 8086. However, it can be demand paged virtual memory to the OS, so that it is easy to swap pages in and out.

When in virtual 8086 mode the processor behaves just like a real 8088/8086, but with some differences. You can alter memory all you want, but touching I/O ports is a bit of a problem. The host OS has to intercept and decide whether to pass the request through to real hardware, emulate it, or do something else. Depending on the host OS that gives you the ability to touch real hardware directly.

OS/2 had a wonderful virtual 8086 mode. You could literally boot DOS 5 in a window, and it would grind the diskette drive just like the real thing. I don't think the modern Windows support is as liberal, but I've not looked into it.

It's certainly easier to exploit a virtual 8086 than it is to write an emulator, but you need access to the host OS. Linux might be a better bet for trying something like that. The virtual 8086 machine looks just like a process to the host OS, except that you are running some funky old DOS code and you need to catch the hardware interrupts. You also have this little problem of simulating a wide range of old school hardware, which may not even be on the machine hosting the virtual 8086. Come to think of it, you might just want to write the emulator. ;-)

IBMMuseum

October 16th, 2006, 06:21 PM

The 80386 introduced 'virtual 8086' mode. The host OS sets up memory a memory region which looks like classic flat real mode addressing inside of the virtual 8086. However, it can be demand paged virtual memory to the OS, so that it is easy to swap pages in and out.

When in virtual 8086 mode the processor behaves just like a real 8088/8086, but with some differences. You can alter memory all you want, but touching I/O ports is a bit of a problem. The host OS has to intercept and decide whether to pass the request through to real hardware, emulate it, or do something else. Depending on the host OS that gives you the ability to touch real hardware directly.

OS/2 had a wonderful virtual 8086 mode. You could literally boot DOS 5 in a window, and it would grind the diskette drive just like the real thing. I don't think the modern Windows support is as liberal, but I've not looked into it.
So for a little programming discussion are we ready to see (from me or others) how a little Assembly (it calls interrupts) can be used to detect if your code is running in an OS/2 or Windows DOS box?

BTW, does anybody else know of the bug starting from Windows 95 where the DOS Environment space is 1Kb larger than specified?

Mike Chambers

October 16th, 2006, 07:22 PM

So for a little programming discussion are we ready to see (from me or others) how a little Assembly (it calls interrupts) can be used to detect if your code is running in an OS/2 or Windows DOS box?

BTW, does anybody else know of the bug starting from Windows 95 where the DOS Environment space is 1Kb larger than specified?

i think there are minor differences in the emulated real mode memory where you could find a difference in some bytes between a windows and an os/2 box. if you can find something this like you would be able to check those bytes from your program and that would allow you to determine which it is.

maybe im wrong... mbbrutman? :)

IBMMuseum

October 16th, 2006, 07:25 PM

i think there are minor differences in the emulated real mode memory where you could find a difference in some bytes between a windows and an os/2 box. if you can find something this like you would be able to check those bytes from your program and that would allow you to determine which it is.

maybe im wrong... mbbrutman? :)
No, there are actually interrupt calls designed for that purpose...

Mike Chambers

October 16th, 2006, 09:10 PM

No, there are actually interrupt calls designed for that purpose...

i should probably have known that.

Chris2005

October 17th, 2006, 09:05 AM

"The 80386 introduced 'virtual 8086' mode. The host OS sets up memory a memory region which looks like classic flat real mode addressing inside of the virtual 8086."

Don't you mean segmented addressing? Or does that happen when virtual-8086 mode gets wrapped up into a command prompt?

"When in virtual 8086 mode the processor behaves just like a real 8088/8086, but with some differences. You can alter memory all you want, but touching I/O ports is a bit of a problem. The host OS has to intercept and decide whether to pass the request through to real hardware, emulate it, or do something else. Depending on the host OS that gives you the ability to touch real hardware directly."

real mode (which even modern processors start up in, then get switched to protected mode by the OS) and virtual-86 mode are two different things though. A processor/OS setups up a virtual machine (or multiples), and that becomes a process as you pointed out. I'm not nitpicking, just trying to understand and get the terminology correct. Then again maybe that is nitpicking...
From what I've read in the distant past, M$ took part in the design of virtual-86 mode, which in reality makes sense because the major impetus was probably to create an environment for all the legacy code built on top of their premier OS. So then, the implementation of a "DOS" prompt was for the purpose of allowing nasty messy old dos apps to run eh unimpeded, so it's going to have to allow low level hardware calls and such, regardless if this is by emulation or not. Printer access and even disk access could be issues, but I thought that disk sectors could be altered (floppy anyway) at least with W95-98. Those are "peripheral" issues though (for many programs, except things like disk editors and whatnot), and "typical" low level access has to be allowed - like accessing the timer chip or whatever.

"You could literally boot DOS 5 in a window..."

If you "run" command.com from the start button, you're executing dos (or at least that version that's specific to the os you're using). NT based OS' aren't "integrated" with a 16 bit dos obviously, so you're running something else? (and please let's not get into a discussion over my using that once nasty nasty term from the Chicago days - integration. I probably should have chose something else altogether).
It's been said on classiccmp recently that you can execute windoze 3.11 (and anything else earlier?) from the command prompt or? run prompt.

"It's certainly easier to exploit a virtual 8086 than it is to write an emulator, but you need access to the host OS."

via DLL's and whatnot?

So essentially I was thinking along the lines that something like the Tandy 2000 could be emulated using virtual-86 mode, depending on if/how you get to tailor the access to low level stuph. Just food for thought.

mbbrutman

October 17th, 2006, 10:07 AM

My bad. 'Flat' is a bad word considering that it is segmented, but compared to having to have page tables, TLBs and demand paging it's pretty flat. It actually is good old segmented 8086.

real mode (which even modern processors start up in, then get switched to protected mode by the OS) and virtual-86 mode are two different things though.

I never said real mode, or discussed real vs. protected. I used the word real to describe how the virtual 8086 interacts with hardware. It's almost like being on real hardware, except for the obvious security problems with allowing unfettered access to I/O ports.

I don't think that running 'command' or 'cmd' from the Start->Run option on Windows gives you a virtual 8086. It looks more like a DOS emulator. If it really were a virtual 8086, it would go through a boot sequence and load DOS from somewhere, and you couldn't access the rest of the Windows NTFS filesystem.

Chris2005

October 17th, 2006, 10:20 AM

"I never said real mode, or discussed real vs. protected. I used the word real to describe how the virtual 8086 interacts with hardware. It's almost like being on real hardware, except for the obvious security problems with allowing unfettered access to I/O ports."

I know you didn't. I was trying to respond to *something*. Maybe it was in a different part of your post. Frankly can't remember.
The reality though is that real mode and virtual-86 mode are sort of similar, but entirely different. O man whatever.

"I don't think that running 'command' or 'cmd' from the Start->Run option on Windows gives you a virtual 8086. It looks more like a DOS emulator. If it really were a virtual 8086, it would go through a boot sequence and load DOS from somewhere, and you couldn't access the rest of the Windows NTFS filesystem."

I seem to recall that in Chuck Sphar's book "Learn Visual C++ 6.0 NOW" he stated that a set of win32 API's are used to not only create the command prompt environment (on the backbone of virtual-86 mode) but the dos-like environment for a console application as well. It's been years, and it amazes me how these things come back to me. I'll have to take another look.
Maybe you're only working in virtual-86 mode with non-NT based OS', or just that the NT "command.com" is just a totally different animal that's programmed to access NTFS partitions. If anyone owns any copy of "Inside Windows" (NT,2000,...), they could probably look it up. I actually may have one copy at mom's house...

Chris2005

October 17th, 2006, 10:21 AM

the book I mentioned is "Learn Microsoft Visual C++ 6.0 NOW". Just to clarify so someone doesn't go nuts searching for it.

Chris2005

October 17th, 2006, 10:24 AM

very good buy on amazon:

http://amazon.com/s/ref=nb_ss_gw/102-2761219-8941756?url=search-alias%3Daps&field-keywords=inside+microsoft+windows+2000

less then 4 bucks. sorry for the plug :)

Chris2005

October 19th, 2006, 04:26 PM

I took another look at the book I mentioned, and v86 mode isn't even mentioned (can't we assume that it's invoked when a dos box is opened, at least with Win9x, ME?). I think my original readings on v86 mode came from a book called the UNAUTHORIZED Windows 95 Developer's Resource Kit
by Andrew Schulman. An interesting book, based on the beta ("Chicago"), which gets pulled apart by the author, but mostly (though not entirely) useless for today's stuph, given the defunct status of that branch of the Windows family.

Online tutorial for 386 stuph:

http://pdos.csail.mit.edu/6.828/2006/readings/i386/c15.htm

IBMMuseum

October 19th, 2006, 06:22 PM

I took another look at the book I mentioned, and v86 mode isn't even mentioned (can't we assume that it's invoked when a dos box is opened, at least with Win9x, ME?)...
No, DOS emulation wouldn't necessarily have to be done with V86 mode...

michal

October 20th, 2006, 10:31 AM

An interesting book, based on the beta ("Chicago"), which gets pulled apart by the author, but mostly (though not entirely) useless for today's stuph, given the defunct status of that branch of the Windows family.

Maybe the beta didn't have the debug info stripped, hence was easier to pull apart... and yes, mostly useless now because NT/XP is a different system, just with the same first name (and mostly compatible api).

On a side note, I remember using "Memphis" (aka windows 97) for a good few years on a daily basis on my PC... Now I'm using Win98 SE. Guess I'm a bit dephunct... :sarcasm:

Chris2005

October 20th, 2006, 10:33 AM

the author could have pulled it apart regardless. If you've never taken a look at the book, it's a worthwhile read. At some point they're probably going to be hard to find, so maybe get one now while the getting is good ;)

mbbrutman

October 20th, 2006, 11:36 AM

No more guessing people's initials. That game is over.

Chris2005

October 20th, 2006, 05:16 PM

No, DOS emulation wouldn't necessarily have to be done with V86 mode...

well...according to Wikipedia:

"It is used to execute DOS programs in Microsoft Windows/386 and Windows 3.x and Windows 9x and Windows Me and OS/2 2.x and later through Virtual DOS machines, in SCO UNIX through Merge and in Linux through dosemu."

The question wasn't if it HAD to be done w/v86 (in Win9x and ME as I pointed out) but IF it were done that way. Apparently it was...

But let me just say I'm so glad we're all paying attention to each other's posts...

mbbrutman

October 20th, 2006, 06:30 PM

I don't believe everything I read in Wikipedia since I recently had an argument with somebody claiming that interpreted BASIC was almost as fast as compiled BASIC.

I think this page has a great description:

http://www.online.ee/~andre/i80386/Chap15.html

Running 'DEBUG' in a DOS window on my Windows 2000 machine showed me this:

C:\WINNT\system32>debug
-r
AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=0B16 ES=0B16 SS=0B16 CS=0B16 IP=0100 NV UP EI PL NZ NA PO NC
0B16:0100 83C205 ADD DX,+05

Note the absence of extended registers .. this really does look like an 8086.

On the other hand:

C:\WINNT\system32>mem

655360 bytes total conventional memory
655360 bytes available to MS-DOS
633184 largest executable program size

1048576 bytes total contiguous extended memory
0 bytes available contiguous extended memory
941056 bytes available XMS memory
MS-DOS resident in High Memory Area

C:\WINNT\system32>

If this really is a virtual 8086, how can it claim to have extended memory? XMS yes, but extended is not possible unless you are on a 286 or greater.

So, I don't know exactly what is doing on here ..

IBMMuseum

October 20th, 2006, 08:32 PM

I don't believe everything I read in Wikipedia since I recently had an argument with somebody claiming that interpreted BASIC was almost as fast as compiled BASIC.
Yes, and I have seen articles that are just flat out wrong...

I think this page has a great description:
http://www.online.ee/~andre/i80386/Chap15.html
Running 'DEBUG' in a DOS window on my Windows 2000 machine showed me this:...
...If this really is a virtual 8086, how can it claim to have extended memory? XMS yes, but extended is not possible unless you are on a 286 or greater.
So, I don't know exactly what is doing on here ..
To be fair this is Windows 2000. For at least the NT+ angle who better to ask than Microsoft?: http://support.microsoft.com/?kbid=99279
"...Although the concept of running an MS-DOS-based application in a Windows-based environment may be familiar to you, Windows NT handles this somewhat differently than Windows (16-bit) does.
The essential difference lies in the command prompt itself; under Windows NT, the command prompt is a 32-bit Windows NT-based application, not the virtual MS-DOS machine you would expect from Windows..."
Later there is talk of PIF files, which have been with Windows since at least 3.x (although the focus area I am looking at is whether EMS can be allocated in a Windows 3.x PIF). And Windows 3.x in "Standard Mode" (286, 386 without at least 2Mb, or 386 with enough RAM but throttled from the commandline) can run DOS boxes (the more limited Windows 3.0 "Real Mode", able to run on an 8086/8088, has to totally shut out of the Windows interface to bring up DOS) where the 286 CPU is not capable of doing V86 mode.

IBMMuseum

October 20th, 2006, 10:27 PM

...Later there is talk of PIF files, which have been with Windows since at least 3.x (although the focus area I am looking at is whether EMS can be allocated in a Windows 3.x PIF). And Windows 3.x in "Standard Mode" (286, 386 without at least 2Mb, or 386 with enough RAM but throttled from the commandline) can run DOS boxes (the older "Real Mode", able to run on an 8086/8088, has to totally shut out of the Windows interface to bring up DOS) where the 286 CPU is not capable of doing V86 mode.
Ok, I found a very good reference right in my own library. "Undocumented DOS", by Andrew Schulman, Ralf Brown [care to dispute him?], David Maxey, Raymond J. Michels, & Jim Kyle. The book is written pre-Windows 95 (which it calls by the codename "Chicago"). Even Windows is discussed more in the terms of 3.0, going over Real, Standard, & Enhanced modes.

Enhanced Mode & Standard mode run the DOS boxes differently. With Enhanced Mode, they say that the code is in the "DOSMGR" VxD, which "is a piece of 32-bit protected mode code running at Ring 0...". In Standard mode (and remember this is normally running on a 286, not able to do V86 mode) it was a DOS extender called DOSX.EXE.

The most talk (of course) is about the Enhanced mode. Notable there is another unassociated VxD called V86MMGR (which manages the EMS 'M'emory for V86 mode). Too much to condense here (and the authors say there was too much material to put in a single book) & an interesting read.

Chris2005

October 21st, 2006, 03:09 PM

so did either of you gurus figure out whether a dos-prompt environment in Win 9x or ME rides on the back of V86 mode? That was was prompted this arm of the discussion...

"(the older "Real Mode", able to run on an 8086/8088, has to totally shut out of the Windows interface to bring up DOS)"

"Real Mode" is very much a part of every peecee, even today's. Even a P4 starts up in real mode, then gets switched to protected mode by Winders or whatever OS that plans to run in it. You can boot up in dos by simply placing a dos disk in the drive (or cd, or a dos partition on a hard drive) and turning on the machine. Then it looks to the OS (dos) like a really really fast 8086, 1 megabyte address space, etc. W/O switching to protected mode, that's where the machine will stay.
To run DOS within Winders or Linux or OS/2...you need some sort of emulation, either in v86 mode, or whatever NT/Linaches/OS/2 etc. uses. Something like that...