Screen control functions

[OziRus]

Hi,

This is my first message on this group. I want to ask something about
screen-drawing functions. I wrote and compiled below code succesfully
on TC IDE in Win-xp. Then i tried to work it on dos but it didn't work.
It runs but doesn't draw anything on screen. Could you say my fault? I
know far,dev and near are a bit problematic in xp but i think compiling
with Tc and running in dos might run it? [I didn't try it on linux yet]

Thanks for everything...

#include <stdio.h>
#include <conio.h>

char far *vp=(char far *)0xB0000000;
void _write(int row,int col,int ch)
{
char far *scrp=vp;
scrp+=row*160+col*2;
*scrp=ch;
}

int main()
{
_write(10,10,'t');
_write(10,11,'e');
_write(10,12,'s');
_write(10,13,'t');
return 0;
}

[OziRus]

not "dev". It was huge :)

[jacob navia]

OziRus wrote:

Hi,

This is my first message on this group. I want to ask something about
screen-drawing functions. I wrote and compiled below code succesfully
on TC IDE in Win-xp. Then i tried to work it on dos but it didn't work.
It runs but doesn't draw anything on screen. Could you say my fault? I
know far,dev and near are a bit problematic in xp but i think compiling
with Tc and running in dos might run it? [I didn't try it on linux yet]

Thanks for everything...

#include <stdio.h>
#include <conio.h>

char far *vp=(char far *)0xB0000000;
void _write(int row,int col,int ch)
{
char far *scrp=vp;
scrp+=row*160+col*2;
*scrp=ch;
}

int main()
{
_write(10,10,'t');
_write(10,11,'e');
_write(10,12,'s');
_write(10,13,'t');
return 0;
}

You have to run under MSDOS, not windows XP.

Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

Contrary to what many people think, the "DOS WINDOW" is just
an EMULATION of text mode msdos, with the same commands,
etc.

The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

Maybe a better idea would be to use the console mode with a 32 bit
compiler, and obtain the same result.

So, you have two solutions:

1) Get a better compiler
2) Get MSDOS and run under msdos by booting from a disquette.
You will get many advantages:
Only 640K of memory. No more problems with that huge amount
of RAM that you do not know what to do about
TC IDE will run better and all dos programs will work.

The choice is yours

jacob

[OziRus]

Thanks for your reply;

jacob navia wrote:

Get a better compiler

Dev C++ couldn't compile the same code that I used with TC. The errors
were like this;

C:\Tc\BIN\KARAKTER.CPP:4: error: expected init-declarator before '*'
token
C:\Tc\BIN\KARAKTER.CPP:4: error: expected `,' or `;' before '*' token
C:\Tc\BIN\KARAKTER.CPP: In function `void _writec(int, int, int)':
C:\Tc\BIN\KARAKTER.CPP:9: error: expected primary-expression before
"char"
C:\Tc\BIN\KARAKTER.CPP:9: error: expected `;' before "char"

C:\Tc\BIN\KARAKTER.CPP:10: error: `scrp' undeclared (first use this
function)
C:\Tc\BIN\KARAKTER.CPP:10: error: (Each undeclared identifier is
reported only once for each function it appears in.)

I couldn't understand why TC compiled and why dev c++ not...

So, I think I should try more interesting methods for drawing. :p

[jacob navia]

OziRus wrote:

Thanks for your reply;

jacob navia wrote:

>Get a better compiler

Dev C++ couldn't compile the same code that I used with TC. The errors
were like this;

C:\Tc\BIN\KARAKTER.CPP:4: error: expected init-declarator before '*'
token
C:\Tc\BIN\KARAKTER.CPP:4: error: expected `,' or `;' before '*' token
C:\Tc\BIN\KARAKTER.CPP: In function `void _writec(int, int, int)':
C:\Tc\BIN\KARAKTER.CPP:9: error: expected primary-expression before
"char"
C:\Tc\BIN\KARAKTER.CPP:9: error: expected `;' before "char"

C:\Tc\BIN\KARAKTER.CPP:10: error: `scrp' undeclared (first use this
function)
C:\Tc\BIN\KARAKTER.CPP:10: error: (Each undeclared identifier is
reported only once for each function it appears in.)

I couldn't understand why TC compiled and why dev c++ not...

So, I think I should try more interesting methods for drawing. :p

I repeat:

You can't move characters and show characters in the screen by
assigning the characters to some pointer as you do now.

In MSDOS, the machine looked at that address to show the 80x24
video display (if I remember correctly).

This is NO LONGER THE CASE unless you still run MSDOS.

Then, you can't compile and RUN that.

If you want to stay under windows xp there is a compatibility
library for turbo c console I/O with lcc-win32 called
tcconio.lib

You have there functions like "highvideo" "clrscr" and similar
functions, all of them with the same interface that turbo C
used for text mode.

You can download the lcc-win32 compiler from
http://www.cs.virginia.edu/~lcc-win32

Note that lcc-win32 will NOT compile the above code
either. You will have to change your functions to:
gotoxy() and puttextA() or similar functions

jacob

[Coos Haak]

Op Sun, 03 Sep 2006 20:06:15 +0200 schreef jacob navia:

The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

But surprisingly it DOES, even under XP. If that gives consoloation ;-)
--
Coos

[Coos Haak]

Op Sun, 03 Sep 2006 20:38:15 +0200 schreef jacob navia:

In MSDOS, the machine looked at that address to show the 80x24
video display (if I remember correctly).

This is NO LONGER THE CASE unless you still run MSDOS.

Then, you can't compile and RUN that.

<OT>
I've used TC 2.01 some time ago and it works with W98 and XP. Don't tell us
nonsense.
</OT>
--
Coos

[J. J. Farrell]

OziRus wrote:

>
This is my first message on this group. I want to ask something about
screen-drawing functions. I wrote and compiled below code succesfully
on TC IDE in Win-xp. Then i tried to work it on dos but it didn't work.
It runs but doesn't draw anything on screen. Could you say my fault? I
know far,dev and near are a bit problematic in xp but i think compiling
with Tc and running in dos might run it? [I didn't try it on linux yet]

Thanks for everything...

#include <stdio.h>
#include <conio.h>

char far *vp=(char far *)0xB0000000;
void _write(int row,int col,int ch)
{
char far *scrp=vp;
scrp+=row*160+col*2;
*scrp=ch;
}

int main()
{
_write(10,10,'t');
_write(10,11,'e');
_write(10,12,'s');
_write(10,13,'t');
return 0;
}

You'd be far better off asking in a group which discusses programming
on MS Windows. comp.lang.c concentrates on the C language itself, and
its aspects and uses which are independent of the system it's running
on. Your program is very dependent on the environment you're using -
for example <conio,his not part of C as such. C itself doesn't have
any concept of a screen, and mechanisms you use to control a screen (on
systems which have one) are different on different Operating Systems.

You'll find far more people who are expert on writing programs specific
to MS operating systems in the newsgroups which are dedicated to the
subject.

[Flash Gordon]

jacob navia wrote:

<snip>

Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

Incorrect. Windows95, Windows98 and even WindowsME actually had DOS 7.x
underneath and in all of them (although with ME it was difficult) you
could get them to boot to a DOS prompt without loading Windows at all.

In addition, you still get some stuff distributed as bootable DOS disk
images. Such as BIOS upgrades. Since this has been the case on some new
machines even after the year 2000 there are obviously still some
programs being run under DOS.

Contrary to what many people think, the "DOS WINDOW" is just
an EMULATION of text mode msdos, with the same commands,
etc.

True.

The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

<snip>

Definitely not entirely true. I've run old DOS based games that did
graphics and sound using their own built in drivers under XP. It might
not really access the screen, but XP traps the attempt (when used in the
correct way) and renders the expected result inside the applications window.

For further discussion on this please go to a Windows group where they
will know all about the compatibility modes of XP.
--
Flash Gordon
--
Flash Gordon

[jacob navia]

Coos Haak wrote:

Op Sun, 03 Sep 2006 20:38:15 +0200 schreef jacob navia:

>>In MSDOS, the machine looked at that address to show the 80x24
video display (if I remember correctly).

This is NO LONGER THE CASE unless you still run MSDOS.

Then, you can't compile and RUN that.

<OT>
I've used TC 2.01 some time ago and it works with W98 and XP. Don't tell us
nonsense.
</OT>

You mean you write into 0xB0000000 and you see the characters
in the screen ???

That would be highly surprising, specially under windows xp

[Joe Wright]

jacob navia wrote:

OziRus wrote:

>Hi,

This is my first message on this group. I want to ask something about
screen-drawing functions. I wrote and compiled below code succesfully
on TC IDE in Win-xp. Then i tried to work it on dos but it didn't work.
It runs but doesn't draw anything on screen. Could you say my fault? I
know far,dev and near are a bit problematic in xp but i think compiling
with Tc and running in dos might run it? [I didn't try it on linux yet]

Thanks for everything...

#include <stdio.h>
#include <conio.h>

char far *vp=(char far *)0xB0000000;
void _write(int row,int col,int ch)
{
char far *scrp=vp;
scrp+=row*160+col*2;
*scrp=ch;
}

int main()
{
_write(10,10,'t');
_write(10,11,'e');
_write(10,12,'s');
_write(10,13,'t');
return 0;
}

You have to run under MSDOS, not windows XP.

Why would that be?

Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

May it RIP.

Contrary to what many people think, the "DOS WINDOW" is just
an EMULATION of text mode msdos, with the same commands,
etc.

No it isn't. The "Command Prompt" is the CLI of either or both of
'command.com' or 'cmd.exe' under Windows 2K and/or Windows XP.

The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

Maybe a better idea would be to use the console mode with a 32 bit
compiler, and obtain the same result.

So, you have two solutions:

1) Get a better compiler
2) Get MSDOS and run under msdos by booting from a disquette.
You will get many advantages:
Only 640K of memory. No more problems with that huge amount
of RAM that you do not know what to do about
TC IDE will run better and all dos programs will work.

The choice is yours

Of course it is. But I find the NTVDM under 2K and XP to be functional
for my purposes. The idea of a DOS boot diskette is just too brutal.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[William J. Leary Jr.]

"OziRus" <ca************@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

This might better be asked in comp.os.msdos.programmer or a windows group.

But...

I know far,dev and near are a bit problematic in xp but i think
compiling with Tc and running in dos might run it?

It should work under a Command Line session (often called a "DOS session")
under XP.

But...

char far *vp=(char far *)0xB0000000;

B0000000 is the Monochrome Display Adapter (MDA) base address.

Some color adapters will emulate the MDA, but most won't. Of the those I've
used, only one (see below).

If you're runing this under Windows, it's going to think it's got a color
adapter of some kind*, so you need B8000000.

I've just compiled your program, as a real mode DOS .EXE, and run it under
MS-DOS 5.0, Windows ME and Windows XP. With B0000000 it only works on the
MS-DOS machine. This one explicitly emulates MDA (as per comment above). If I
use B8000000 it works as expected under all three.

- Bill
____________
* Your display adapter probably has to emulate the Color Graphics Adapter (CGA)
for this to work. The majority of adapters do or, at least, did last time I
shopped around (about six months back).

[jacob navia]

Joe Wright wrote:

jacob navia wrote:

>OziRus wrote:

>>Hi,

This is my first message on this group. I want to ask something about
screen-drawing functions. I wrote and compiled below code succesfully
on TC IDE in Win-xp. Then i tried to work it on dos but it didn't work.
It runs but doesn't draw anything on screen. Could you say my fault? I
know far,dev and near are a bit problematic in xp but i think compiling
with Tc and running in dos might run it? [I didn't try it on linux yet]

Thanks for everything...

#include <stdio.h>
#include <conio.h>

char far *vp=(char far *)0xB0000000;
void _write(int row,int col,int ch)
{
char far *scrp=vp;
scrp+=row*160+col*2;
*scrp=ch;
}

int main()
{
_write(10,10,'t');
_write(10,11,'e');
_write(10,12,'s');
_write(10,13,'t');
return 0;
}

You have to run under MSDOS, not windows XP.

Why would that be?

>Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

May it RIP.

>Contrary to what many people think, the "DOS WINDOW" is just
an EMULATION of text mode msdos, with the same commands,
etc.

No it isn't. The "Command Prompt" is the CLI of either or both of
'command.com' or 'cmd.exe' under Windows 2K and/or Windows XP.

Yes, that is a better description. But you will agree that this "cli"
has commands like

DIR

that remember me an older system. In that sense it is an emulation of a
previous environment.

>

>The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

Maybe a better idea would be to use the console mode with a 32 bit
compiler, and obtain the same result.

So, you have two solutions:

1) Get a better compiler
2) Get MSDOS and run under msdos by booting from a disquette.
You will get many advantages:
Only 640K of memory. No more problems with that huge amount
of RAM that you do not know what to do about
TC IDE will run better and all dos programs will work.

The choice is yours

Of course it is. But I find the NTVDM under 2K and XP to be functional
for my purposes. The idea of a DOS boot diskette is just too brutal.

<OT>

Why?

Digital research and MAXTOR offer an MSDOS disquette that when
you boot it will test the hard disk. Cute isn't it?

Besides MSDOS under emulation will never be exactly like
the true MSDOS.

[jacob navia]

Flash Gordon wrote:

jacob navia wrote:

<snip>

>Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

Incorrect. Windows95, Windows98 and even WindowsME actually had DOS 7.x
underneath and in all of them (although with ME it was difficult) you
could get them to boot to a DOS prompt without loading Windows at all.

True, but not under windows xp, the system the OP said he
was using.

In addition, you still get some stuff distributed as bootable DOS disk
images. Such as BIOS upgrades. Since this has been the case on some new
machines even after the year 2000 there are obviously still some
programs being run under DOS.

True. I used one yesterday from MAXTOR. It boots
MSDOS (Digital Research) and tests your MAXTOR hard drive.

>Contrary to what many people think, the "DOS WINDOW" is just
an EMULATION of text mode msdos, with the same commands,
etc.

True.

>The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

<snip>

Definitely not entirely true. I've run old DOS based games that did
graphics and sound using their own built in drivers under XP. It might
not really access the screen, but XP traps the attempt (when used in the
correct way) and renders the expected result inside the applications
window.

Yes, you can change the emulator behavior with the "shortcut properties"
if I remember correctly, and maybe it emulates that hacks too.

For further discussion on this please go to a Windows group where they
will know all about the compatibility modes of XP.

AHHHH

Nostalgia is not what it used to be ...

:-)

[jacob navia]

William J. Leary Jr. wrote:

"OziRus" <ca************@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

This might better be asked in comp.os.msdos.programmer or a windows group.

But...

>>I know far,dev and near are a bit problematic in xp but i think
compiling with Tc and running in dos might run it?

It should work under a Command Line session (often called a "DOS session")
under XP.

But...

>>char far *vp=(char far *)0xB0000000;

B0000000 is the Monochrome Display Adapter (MDA) base address.

Some color adapters will emulate the MDA, but most won't. Of the those I've
used, only one (see below).

If you're runing this under Windows, it's going to think it's got a color
adapter of some kind*, so you need B8000000.

I've just compiled your program, as a real mode DOS .EXE, and run it under
MS-DOS 5.0, Windows ME and Windows XP. With B0000000 it only works on the
MS-DOS machine. This one explicitly emulates MDA (as per comment above). If I
use B8000000 it works as expected under all three.

- Bill
____________
* Your display adapter probably has to emulate the Color Graphics Adapter (CGA)
for this to work. The majority of adapters do or, at least, did last time I
shopped around (about six months back).

Bill (Your second names isn't Gates I presume ? :-)

You are a TRUE MSDOS HACKER (tm)

This is actually the reason!!!!

Congratulations Bill.

jacob

[Flash Gordon]

OziRus wrote:

Hi,

This is my first message on this group. I want to ask something about
screen-drawing functions.

To do screen drawing you need things beyond standard C. So you would be
best off asking in a group dedicated to your platform.

I wrote and compiled below code succesfully
on TC IDE in Win-xp. Then i tried to work it on dos but it didn't work.

When you go to a Windows group you should be more explicit. Tell them
which version of TC etc. They will probably tell you to upgrade to a
more recent version that actually has proper support for XP.

It runs but doesn't draw anything on screen. Could you say my fault? I
know far,dev and near are a bit problematic in xp but i think compiling

far and near are nothing to do with C. They are extensions that some
compilers used to provide.

with Tc and running in dos might run it? [I didn't try it on linux yet]

No chance of it working in Linux unless you run it under a DOS emulator.

Thanks for everything...

#include <stdio.h>
#include <conio.h>

Non-standard header. However, it (and the library that go with it) might
provide some of the facility you want.

char far *vp=(char far *)0xB0000000;

far, as I say, is not part of the C language. In any case, there is no
guarantee your screen (or emulated screen in DOS compatibility mode on
XP is at that location. IIRC the location depended to an extent on the
type of graphics card, CGA, EGA and VGA being at different locations. I
could be wrong. Ask on a DOS group.

void _write(int row,int col,int ch)

Don't use names starting with an underscore. There are some you can use
in some conditions but it is not worth the effort of remembering what
you are allowed to do, far simpler to just avoid them.

<snip>
--
Flash Gordon

[Coos Haak]

Op Sun, 03 Sep 2006 23:14:09 +0200 schreef jacob navia:

Coos Haak wrote:

>Op Sun, 03 Sep 2006 20:38:15 +0200 schreef jacob navia:

>>>In MSDOS, the machine looked at that address to show the 80x24
video display (if I remember correctly).

This is NO LONGER THE CASE unless you still run MSDOS.

Then, you can't compile and RUN that.

<OT>
I've used TC 2.01 some time ago and it works with W98 and XP. Don't tell us
nonsense.
</OT>

You mean you write into 0xB0000000 and you see the characters
in the screen ???

That would be highly surprising, specially under windows xp

<OT>
I would not do that, but writing to 0xB800:0000 still has effect.
Mind you, TC is a 16 bit application. It can't write to a 32 bit long
address.
</OT>
--
Coos

[William J. Leary Jr.]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:44***********************@news.orange.fr...

William J. Leary Jr. wrote:

I've just compiled your program, as a real mode DOS .EXE, and run it under
MS-DOS 5.0, Windows ME and Windows XP. With B0000000 it only works on the
MS-DOS machine. This one explicitly emulates MDA (as per comment above).

If I

use B8000000 it works as expected under all three.

Bill (Your second names isn't Gates I presume ? :-)

No. "Junior" was born two days after me.

You are a TRUE MSDOS HACKER (tm)

I did a great deal of CP/M and MS-DOS programming. A lot of it direct to
hardware, mostly in K&R C and assembler. Still do some MS-DOS stuff, but in
(almost)ANSI-C and Oberon these days.

This is actually the reason!!!!

Congratulations Bill.

Thanks.

- Bill

[Keith Thompson]

"OziRus" <ca************@gmail.comwrites:

This is my first message on this group. I want to ask something about
screen-drawing functions. I wrote and compiled below code succesfully
on TC IDE in Win-xp. Then i tried to work it on dos but it didn't work.
It runs but doesn't draw anything on screen. Could you say my fault? I
know far,dev and near are a bit problematic in xp but i think compiling
with Tc and running in dos might run it? [I didn't try it on linux yet]

Thanks for everything...

#include <stdio.h>
#include <conio.h>

char far *vp=(char far *)0xB0000000;
void _write(int row,int col,int ch)
{
char far *scrp=vp;
scrp+=row*160+col*2;
*scrp=ch;
}

int main()
{
_write(10,10,'t');
_write(10,11,'e');
_write(10,12,'s');
_write(10,13,'t');
return 0;
}

Apart from the system-specificity of your code, it's a bad idea to use
identifiers starting with an underscore:

All identifiers that begin with an underscore and either an
uppercase letter or another underscore are always reserved for any
use.

All identifiers that begin with an underscore are always reserved
for use as identifiers with file scope in both the ordinary and
tag name spaces.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[snip]

You have to run under MSDOS, not windows XP.

Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

Contrary to what many people think, the "DOS WINDOW" is just
an EMULATION of text mode msdos, with the same commands,
etc.

[snip]

Contrary to what jacob navia seems to think, this newsgroup discusses
the C programming language, not MSDOS or Windows.

There are plenty of newsgroups that do discuss those operating
systems. The OP's question, and jacob's answer, would be appropriate
in one of them.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

jacob navia wrote:

Flash Gordon wrote:

>jacob navia wrote:

<snip>

>>Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

Incorrect. Windows95, Windows98 and even WindowsME actually had DOS
7.x underneath and in all of them (although with ME it was difficult)
you could get them to boot to a DOS prompt without loading Windows at
all.

True, but not under windows xp, the system the OP said he
was using.

Therefore what you said was false. DOS has *not* been dead for more than
10 years. If you are talking about XP specifically, that is under 10
years old so you were *still* wrong.

>In addition, you still get some stuff distributed as bootable DOS disk
images. Such as BIOS upgrades. Since this has been the case on some
new machines even after the year 2000 there are obviously still some
programs being run under DOS.

True. I used one yesterday from MAXTOR. It boots
MSDOS (Digital Research) and tests your MAXTOR hard drive.

If it is the Digital Research version then it is DRDOS *not* MSDOS.
There are other versions of DOS as well. However, this agrees with what
I said that you were *wrong* to claim that DOS is dead.

<snip>

>>The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

Definitely not entirely true. I've run old DOS based games that did
graphics and sound using their own built in drivers under XP. It might
not really access the screen, but XP traps the attempt (when used in
the correct way) and renders the expected result inside the
applications window.

Yes, you can change the emulator behavior with the "shortcut properties"
if I remember correctly, and maybe it emulates that hacks too.

So you were wrong here as well. This is why you should direct posters to
the *correct* group. It is pure chance that a couple of us happen to
know a little more about this that you do. Enough to point out that you
were almost completely wrong and definitely completely wrong about the
points that affect the OP.

>For further discussion on this please go to a Windows group where they
will know all about the compatibility modes of XP.

AHHHH

Nostalgia is not what it used to be ...

:-)

So don't post advice about things you have forgotten (if you ever knew
them). Instead redirect people to appropriate groups where they will
find the *real* experts on the topic when it is not topical here.
--
Flash Gordon

[jacob navia]

Flash Gordon wrote:

jacob navia wrote:

>Flash Gordon wrote:

>>jacob navia wrote:

<snip>

Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

Incorrect. Windows95, Windows98 and even WindowsME actually had DOS
7.x underneath and in all of them (although with ME it was difficult)
you could get them to boot to a DOS prompt without loading Windows at
all.

True, but not under windows xp, the system the OP said he
was using.

Therefore what you said was false. DOS has *not* been dead for more than
10 years. If you are talking about XP specifically, that is under 10
years old so you were *still* wrong.

MSDOS was dead when windows 95 came out.
Microsoft has discontinued support for it YEARS ago.
Yes, in some embedded systems it goes on, just as the
VAX is somehwere maybe still running, and I do not know if
you know this, but I can run even a PDP11 in emulation
now.

But (I hope) you will agree with me that MSDOS is quite dead since quite
a few years!!!

>>In addition, you still get some stuff distributed as bootable DOS
disk images. Such as BIOS upgrades. Since this has been the case on
some new machines even after the year 2000 there are obviously still
some programs being run under DOS.

True. I used one yesterday from MAXTOR. It boots
MSDOS (Digital Research) and tests your MAXTOR hard drive.

If it is the Digital Research version then it is DRDOS *not* MSDOS.
There are other versions of DOS as well. However, this agrees with what
I said that you were *wrong* to claim that DOS is dead.

Digital Research still distributes that stuff, and it is still used.
Besides, the PDP 11 emulator is still running, and I can emulate
an Apple ][ in the Mac. Software never dies.

But in *some* sense, the PDP 11 *is dead* !!!

<snip>

>>>The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.
Definitely not entirely true. I've run old DOS based games that did
graphics and sound using their own built in drivers under XP. It
might not really access the screen, but XP traps the attempt (when
used in the correct way) and renders the expected result inside the
applications window.

Yes, you can change the emulator behavior with the "shortcut properties"
if I remember correctly, and maybe it emulates that hacks too.

So you were wrong here as well. This is why you should direct posters to
the *correct* group. It is pure chance that a couple of us happen to
know a little more about this that you do. Enough to point out that you
were almost completely wrong and definitely completely wrong about the
points that affect the OP.

>>For further discussion on this please go to a Windows group where
they will know all about the compatibility modes of XP.

AHHHH

Nostalgia is not what it used to be ...

:-)

So don't post advice about things you have forgotten (if you ever knew
them). Instead redirect people to appropriate groups where they will
find the *real* experts on the topic when it is not topical here.

The advice I gave the OP was to get a more up-to-date system and
environment. In my first answer said

Get a better compiler

That stills tands and it is not wrong.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

MSDOS was dead when windows 95 came out.
Microsoft has discontinued support for it YEARS ago.

[...]

Yes, in some embedded systems it goes on, just as the
VAX is somehwere maybe still running, and I do not know if
you know this, but I can run even a PDP11 in emulation
now.

But (I hope) you will agree with me that MSDOS is quite dead since
quite a few years!!!

I will neither agree nor disagree, because I do not care. The
question has nothing to do with the C programming language, and is
therefore off topic in this newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[OziRus]

Thanks "Bill". I got it.
jacob navia wrote:

William J. Leary Jr. wrote:

"OziRus" <ca************@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

This might better be asked in comp.os.msdos.programmer or a windows group.

But...

>I know far,dev and near are a bit problematic in xp but i think
compiling with Tc and running in dos might run it?

It should work under a Command Line session (often called a "DOS session")
under XP.

But...

>char far *vp=(char far *)0xB0000000;

B0000000 is the Monochrome Display Adapter (MDA) base address.

Some color adapters will emulate the MDA, but most won't. Of the those I've
used, only one (see below).

If you're runing this under Windows, it's going to think it's got a color
adapter of some kind*, so you need B8000000.

I've just compiled your program, as a real mode DOS .EXE, and run it under
MS-DOS 5.0, Windows ME and Windows XP. With B0000000 it only works on the
MS-DOS machine. This one explicitly emulates MDA (as per comment above). If I
use B8000000 it works as expected under all three.

- Bill
____________
* Your display adapter probably has to emulate the Color Graphics Adapter (CGA)
for this to work. The majority of adapters do or, at least, did last time I
shopped around (about six months back).

Bill (Your second names isn't Gates I presume ? :-)

You are a TRUE MSDOS HACKER (tm)

This is actually the reason!!!!

Congratulations Bill.

jacob

[Flash Gordon]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

<snip>

I will neither agree nor disagree, because I do not care. The
question has nothing to do with the C programming language, and is
therefore off topic in this newsgroup.

I do care and I know, but I agree this is the wrong place for it. I've
taken it to email.
--
Flash Gordon

[Kenneth Brody]

jacob navia wrote:

>
OziRus wrote:

[...]

char far *vp=(char far *)0xB0000000;

[...]

You have to run under MSDOS, not windows XP.

Contrary to what *many* people think, MSDOS is dead since more than 10
years, I do not remember exactly when was it, maybe 1995.

And, contrary to that, Windows 95, 98, and Me all run on top of MS-DOS,
despite what Microsoft would have liked you to believe.

Contrary to what many people think, the "DOS WINDOW" is just
an EMULATION of text mode msdos, with the same commands,
etc.

The MSDOS emulation will NOT emulate the writing to screen memory,
as it seems.

Yes it does, _if_ you are running a 16-bit MS-DOS program.

<drift mode="even further OT">

In a console window, type "debug". Then, at the debugger's "-" prompt,
type "f b800:0 l400 41 04". (Note that "l400" is "el four zero zero",
and "41" is "four one".) The first 6-1/2 lines will fill with red "A"s.
(Character 0x41, attribute 0x04.)

Also, note that the address is "b800:0000", not "b000:0000" as the
code from the OP used. If the compiler is generating 16-bit real-mode
executables, then changing to 0xb8000000 may "fix" the problem.

</drift>

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>