RDOS Multi-core Support

[Marty Stanquist]

Does RDOS currently run on multi-core cpu's and if so, does it make use of
all the cores?

[Leif Ekblad]

Yes to both. RDOS does run on multicore if configured properly (setup with
APIC device-driver)
and uses all available cores if load is sufficient. A dual core
configuration requires the C-based
ACPI device-driver, so such a configuration is a good choice for a test
environment.

If you want to install RDOS, the best way is to use GRUB boot-loader. I can
help you with this procedure.

Looking at your proposed hardware configurations, both of them should run
RDOS. I have a machine with
a dual core Athlon, and it works. I've also tested with a configuration with
a Intel Celeron.

Also remember that RDOS is not a host system, and thus will not build the
OpenWatcom project. It is only
intended as a target system. At least for now.

Leif Ekblad

Post by Marty Stanquist
Does RDOS currently run on multi-core cpu's and if so, does it make use of
all the cores?

[Leif Ekblad]

There is also the issue of which keyboard the computer has. The best
alternative is a PS/2 keyboard. An USB keyboard could work, provided the
machine has an UHCI or OHCI chip, but that configuration is a lot more
problematic on typical machines.

For a disk IDE is best (or a SATA disk set to IDE emulation in BIOS). Native
SATA (AHCI) could work as well but is less well tested. SCSI or USB discs
are currently not supported. You would want to have a FAT16 or FAT32
partition. NTFS, HPFS or EXT will not work. OTOH, it is possible to run RDOS
without a supported disk / partition.

Going further, if you want remote debug functionality, you also want a
supported network card. Here the best alternative is an RTL8139, RTL816x,
RTL811x or similar as there are working drivers for those.

Video card support is often not a problem. The requirement is a VBE
compatible video card that support linear frame buffer (LFB). A majority of
the video cards manufactured the last 10-15 years meet these requirements,
but there are a few which has faulty mode-set code. OTOH, it is not necesary
to have a supported video card for running only command-line. This is only
required for running graphical applications.

Leif Ekblad

[Marty Stanquist]

If we test RDOS, FreeDOS, OpenDOS (or DRDOS), and MS-DOS 6.22, will this be
sufficient? I was also having trouble redirecting both stderr and stdout to
a file in MS-DOS 6.22. Did Microsoft not support constructs like "command >
file 2>&1" until Windows NT?

Marty

[Paul S. Person]

On Mon, 2 Jul 2012 17:42:12 -0500, "Marty Stanquist"

Post by Marty Stanquist
If we test RDOS, FreeDOS, OpenDOS (or DRDOS), and MS-DOS 6.22, will this be
sufficient? I was also having trouble redirecting both stderr and stdout to
a file in MS-DOS 6.22. Did Microsoft not support constructs like "command >
file 2>&1" until Windows NT?

When I upgraded to OS/2 Warp 4 I created an "MS-DOS 6.22" program
object because Lantastic 8 had worked in such a session under OS/2
Warp 3.x. Unfortunately, it did not worked as well with OS/2 Warp 4.
Actually, that may have been a good thing: it prompted me to use
OS/2's own networking, which has definite advantages over Lantastic
running in a single DOS session.

For those unfamiliar with this capability, this object runs an MS-DOS
6.22 command-line session (using an installation of MS-DOS 6.22 on the
same computer), not an MDOS session. IIRC, this involves creating a
floppy with some special drivers in config.sys that OS/2 can "boot" to
produce such a session, and then converting it to an image file.

Testing with the line indicated:

command file 2>&1

doesn't actually work (it, in fact, hangs the DOS session) -- but it
does create an empty file named "&1".

Perhaps if you provided an example that should actually work, and
explain what it is supposed to do, I could test it. I'm afraid my
imagination no longer extends to this sort of thing.

If necessary, I can reboot my OS/2 machine into genuine MS-DOS 6.22
and try it there.

[Hans-Bernhard Bröker]

Post by Marty Stanquist
I was also having trouble redirecting both stderr and
stdout to a file in MS-DOS 6.22. Did Microsoft not support constructs
like "command > file 2>&1" until Windows NT?

Indeed, except the blame isn't exactly on MS-DOS as such. It's on the
command processor. It is command.com that doesn't support redirecting
stderr in any way, neither 2>file nor 2>&1. It took MS more than long
enough to realize this was a shortcoming important enough to fix.

[E. S. Fabian]

Hans-Bernhard Bröker:

|| On 03.07.2012 00:42, Marty Stanquist wrote:
||| I was also having trouble redirecting both stderr and
||| stdout to a file in MS-DOS 6.22. Did Microsoft not support
||| constructs like "command > file 2>&1" until Windows NT?
||
|| Indeed, except the blame isn't exactly on MS-DOS as such. It's on
|| the command processor. It is command.com that doesn't support
|| redirecting stderr in any way, neither 2>file nor 2>&1. It took MS
|| more than long enough to realize this was a shortcoming important
|| enough to fix.

You can use the freeware version of 4OS2 or 4DOS - both are much more
advanced than COMMAND.COM and do correctly redirect STDERR, either to a
separate file or to the same file as STDOUT.

[Bartosz Polednia]

Post by E. S. Fabian
||| I was also having trouble redirecting both stderr and
||| stdout to a file in MS-DOS 6.22. Did Microsoft not support
||| constructs like "command> file 2>&1" until Windows NT?
||
|| Indeed, except the blame isn't exactly on MS-DOS as such. It's on
|| the command processor. It is command.com that doesn't support
|| redirecting stderr in any way, neither 2>file nor 2>&1. It took MS
|| more than long enough to realize this was a shortcoming important
|| enough to fix.
You can use the freeware version of 4OS2 or 4DOS - both are much more
advanced than COMMAND.COM and do correctly redirect STDERR, either to a
separate file or to the same file as STDOUT.

http://www.4dos.info/v4dos.htm

[Marty Stanquist]

Thanks, I 'll start using 4OS2 and 4DOS. I was unzipping files using the DOS
program unzip32.exe in a batch routine. When you use the -t (test) command
line option, it outputs the messages to STDERR. When you use the -l (list)
command line option, it outputs the messages to STDOUT. Additionally, I
have verified that both my DOS and OS/2 test machines have SATA hard
drives.This should support RDOS and eCS. I'll be testing MS-DOS 6.22 using a
2GB FAT-16 partition and RDOS, FreeDOS, and OpenDOS (DR-DOS) using 23GB
FAT-32 partitions. Eventually, I'd like to get the machines connected to a
Novell Netware 6.5 server, but I'll try connecting them to eCS and Windows
XP first. For DOS networking, I understand that you need to load a board
specific Ethernet driver then a more general packet driver. Dell Computer
has both drivers on their website. For DOS, eCS, and Windows XP, I'll be
using Dell Optiplex 270/280 Pentium 4 machines with Broadcom NetXtreme 57xx
and Intel Pro Gigabit Ethernet chips. Both machines will be multi-boot using
the Grub boot loader. Let me know if you have any suggestions and I'll keep
you posted on the results.

Marty

Post by E. S. Fabian
||| I was also having trouble redirecting both stderr and
||| stdout to a file in MS-DOS 6.22. Did Microsoft not support
||| constructs like "command> file 2>&1" until Windows NT?
||
|| Indeed, except the blame isn't exactly on MS-DOS as such. It's on
|| the command processor. It is command.com that doesn't support
|| redirecting stderr in any way, neither 2>file nor 2>&1. It took MS
|| more than long enough to realize this was a shortcoming important
|| enough to fix.
You can use the freeware version of 4OS2 or 4DOS - both are much more
advanced than COMMAND.COM and do correctly redirect STDERR, either to a
separate file or to the same file as STDOUT.

http://www.4dos.info/v4dos.htm

[Marty Stanquist]

Sorry I've been offline for a few days. I got locked out of my Windows 7
machine after repartitioning the hard drive and installing FreeBSD as a
second OS. I now have the Nvidia driver and dual boot working, so I should
be back to business as usual. I'm trying to move all my development work off
of Windows and onto FreeBSD for memory utilization reasons. We're porting OW
to BSD, Solaris, and OS X as part of the V2.0 effort, so this will
eventually help me get more use out of my main PC. I'll talk more about this
in the blog. I'm very interested in the work that's currently underway for
RDOS and eCS and I'm almost finished configuring the test machines. I didn't
hear back from Roderick Klein at Mensys this week and will email him again.
RDOS, eCS, and Windows 7 bug fixes will be the focus of the testing.

Marty

[Lynn McGuire]

Post by Marty Stanquist
Sorry I've been offline for a few days. I got locked out of my Windows 7
machine after repartitioning the hard drive and installing FreeBSD as a
second OS. I now have the Nvidia driver and dual boot working, so I
should be back to business as usual. I'm trying to move all my
development work off of Windows and onto FreeBSD for memory utilization
reasons. We're porting OW to BSD, Solaris, and OS X as part of the V2.0
effort, so this will eventually help me get more use out of my main PC.
I'll talk more about this in the blog. I'm very interested in the work
that's currently underway for RDOS and eCS and I'm almost finished
configuring the test machines. I didn't hear back from Roderick Klein at
Mensys this week and will email him again. RDOS, eCS, and Windows 7 bug
fixes will be the focus of the testing.
Marty

Blog ?

Lynn

[Lynn McGuire]

Post by Lynn McGuire

Post by Marty Stanquist
Sorry I've been offline for a few days. I got locked out of my Windows 7
machine after repartitioning the hard drive and installing FreeBSD as a
second OS. I now have the Nvidia driver and dual boot working, so I
should be back to business as usual. I'm trying to move all my
development work off of Windows and onto FreeBSD for memory utilization
reasons. We're porting OW to BSD, Solaris, and OS X as part of the V2.0
effort, so this will eventually help me get more use out of my main PC.
I'll talk more about this in the blog. I'm very interested in the work
that's currently underway for RDOS and eCS and I'm almost finished
configuring the test machines. I didn't hear back from Roderick Klein at
Mensys this week and will email him again. RDOS, eCS, and Windows 7 bug
fixes will be the focus of the testing.
Marty

Blog ?
Lynn

I did see this blog ?
http://openwatcom.org/index.php/Open_Watcom_Reflections

Thanks,
Lynn

[Marty Stanquist]

Yes, Open Watcom Reflections is now part of the website. It's accessible via
the link below or click on Reflections Blog at the bottom of the navigation
panel. The first blog is introductory. I'll be making corrections that were
suggested for UTC time/date, Peter and Michal's contributions, and adding
links to references and previous issues. Upcoming blogs will discuss our
platform support, testing and release activities, website enhancements, and
plans for generation 2.x. I hope to keep the blog informal and appealing to
a wide audience. Here is the link:

Navigation>Reflections Blog
or
http://www.openwatcom.org/index.php/Open_Watcom_Reflections

Marty

[Lynn McGuire]

Yes, Open Watcom Reflections is now part of the website. It's accessible via the link below or click on Reflections Blog at the
bottom of the navigation panel. The first blog is introductory. I'll be making corrections that were suggested for UTC time/date,
Peter and Michal's contributions, and adding links to references and previous issues. Upcoming blogs will discuss our platform
support, testing and release activities, website enhancements, and plans for generation 2.x. I hope to keep the blog informal and
Navigation>Reflections Blog
or
http://www.openwatcom.org/index.php/Open_Watcom_Reflections
Marty

Thanks !

Lynn