Bug/problem with lcc-win

[Eddie]

Hi

I am using lcc-win on Windows 98. I'm writing a simple c console app, and
I need to set the background color to blue. Here's the code I've got at
the moment:

_asm ( "movb $2, %ah\n"
"movb $7, %dl\n"
"int $0x21\n"
);

But this doesn't work.

Does anyone have any suggestions?

Thanks.

[Eddie]

I think it must be possible, because on Windows 98 it's still possible to
run MS-DOS programs. I believe Microsoft's compiler will let you do it.

I agree that the C version is easier to understand than the assembly, but
my situation is that I've got lots of bespoke programs for insurance sales
etc. on DOS, and the company is upgrading to Windows 98, so for getting
them ported it would be much better if lcc-win was backward compatible.

It would be also good to be able to use the same compiler both on DOS and
Windows, but I didn't see a DOS version of lcc-win on the website - is
there somewhere I can get one?

Thanks.

On Wed, 04 Jun 2008 01:11:09 +0200, jacob navia wrote:

Walter Roberson wrote:

>In article <pa************ *************** *@nospam.com>,
Eddie <no****@nospam. comwrote:

>>I think it would still be better if lcc-win supported writing directly to
video memory as well as using #tconio, this would make it much easier
when porting applications.

You are expecting that lcc-win, a *compiler*, would somehow detect
and intercept your assembler 'int' (interrupt) instruction, figure
out from historical patterns what the interrupt used to do, and
then rewrite the code to make the calls that the new operating
system requires instead ?? But then since you are down in the
assembler level, it would have to change the assembler code
generated to insert the new necessary calls, and that could mess
up any branch or load-relative offsets you had hand-coded.

Or are you expecting that lcc-win, a *compiler*, would hook itself
in to the interrupt vectors, figure out what the received interrupt
used to do, and make the new system calls instead? But then since
you are down in the assembler level, you might have specified your
own interrupt vector and your interrupt code might get bolluxed if
lcc-win front-ended your interrupt code.

In my opinion, what you are asking for is unreasonable to expect a
C compiler to do on a different operating system than the one
that the embedded assembler source was coded for.

That is the main point. That assembler code worked on DOS. Now,
since DOS is gone, it doesn't work anymore and you just use C
instead of assembly. Somehow I find

textbackground( BLUE);

much clearer than the assembler instructions isn't it?

If you have further questions please go to the group
comp.compilers. lcc

This discussion is ot very topical here.

[Ian Collins]

Eddie wrote:

[off topic stuff]

Please stop

a) top-posting and

b) posting off topic comments that belong elsewhere.

--
Ian Collins.

[Richard Heathfield]

Eddie said:

I think it must be possible, because on Windows 98 it's still possible to
run MS-DOS programs. I believe Microsoft's compiler will let you do it.

Not since version 7 or so (MSVC1.5x). If you have that, great. Otherwise,
consider Borland C or Turbo C, both of which support 16-bit DOS programs,
as (I think, but I'm not sure) does DJGPP.

You might want to take this discussion to another group, though - here we
discuss the raw C language, not extensions for particular platforms. Your
best bet might be comp.os.msdos.p rogrammer or perhaps
comp.os.ms-windows.program mer.win32.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Serve Lau]

"Eddie" <no****@nospam. comschreef in bericht
news:pa******** *************** *****@nospam.co m...

>I think it must be possible, because on Windows 98 it's still possible to
run MS-DOS programs. I believe Microsoft's compiler will let you do it.

I agree that the C version is easier to understand than the assembly, but
my situation is that I've got lots of bespoke programs for insurance sales
etc. on DOS, and the company is upgrading to Windows 98, so for getting
them ported it would be much better if lcc-win was backward compatible.

Obviously you dont know what you're talking about. Just keep it at what you
want is not possible. It's silly to ask for a compiler for one OS (windows)
to generate code for another (dos) And no it doesnt work with microsoft
compilers either.

>
It would be also good to be able to use the same compiler both on DOS and
Windows, but I didn't see a DOS version of lcc-win on the website - is
there somewhere I can get one?

Or better yet, remove the assembler and put in the C functions? You are
getting paid for it so putting in a little work wont hurt anybody. And
another thing, why is that company moving from one unsupported OS to another
unsupported OS?

[Richard Heathfield]

Serve Lau said:

>
"Eddie" <no****@nospam. comschreef in bericht
news:pa******** *************** *****@nospam.co m...

>>I think it must be possible, because on Windows 98 it's still possible to
run MS-DOS programs. I believe Microsoft's compiler will let you do it.

I agree that the C version is easier to understand than the assembly,
but my situation is that I've got lots of bespoke programs for insurance
sales etc. on DOS, and the company is upgrading to Windows 98, so for
getting them ported it would be much better if lcc-win was backward
compatible.

Obviously you dont know what you're talking about.

Do you?

Just keep it at what you want is not possible.

Saying it's not possible doesn't make it not possible. And it turns out
that it *is* possible. It may be possible with lcc-win - I don't know -
but it's certainly possible with some other compilers.

It's silly to ask for a compiler for one OS
(windows) to generate code for another (dos)

Nevertheless, compilers exist which run under Windows but which can produce
DOS executables. I have at least three such compilers lying around the
place.

And no it doesnt work with
microsoft compilers either.

It does with some Microsoft compilers. For example, MSVC1.5x.

<snip>

And
another thing, why is that company moving from one unsupported OS to
another unsupported OS?

Possibly because they want stability. There are still people around who
prefer not to fix something that isn't broken or, if it *is* broken, want
to apply the minimum fix possible. That's their decision, not ours.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

Serve Lau said:

>"Eddie" <no****@nospam. comschreef in bericht
news:pa******* *************** ******@nospam.c om...

>>I think it must be possible, because on Windows 98 it's still possible to
run MS-DOS programs. I believe Microsoft's compiler will let you do it.

I agree that the C version is easier to understand than the assembly,
but my situation is that I've got lots of bespoke programs for insurance
sales etc. on DOS, and the company is upgrading to Windows 98, so for
getting them ported it would be much better if lcc-win was backward
compatible.

Obviously you dont know what you're talking about.

Do you?

He knows more than you apparently.

>Just keep it at what you want is not possible.

Saying it's not possible doesn't make it not possible. And it turns out
that it *is* possible. It may be possible with lcc-win - I don't know -
but it's certainly possible with some other compilers.

No.

Win32 runs in 32 bits, DOS runs on 16 bits.

Win32 can EMULATE msdos, and yes, you can generate 16 bit
executables for msdos using for instance, a linux 64 bit OS.

So what?
It is NOT possible under win32 to access video memory in the old
DOS way!

When you make an interrupt (21 for instance) the interrupt goes
to Win32 table of interrupts that are NOT compatible with msdos!

Now, if you are running under 16 bit MSDOS emulation, the interrupt
will be trapped by the emulation layer and redirected to simulate some
video memory. But this is done with 16 bit programs only, NOT
with 32 bit programs!

>It's silly to ask for a compiler for one OS
(windows) to generate code for another (dos)

Nevertheless, compilers exist which run under Windows but which can produce
DOS executables.

As I said above, you can use linux 64 bits to generate
code for msdos 16 bits if you like. Under linux 64 bits
you can run an msdos emulator with turboc.

That doesn't mean that you can use the interrupt 21 under
linux 64 to set the text screen background!

I have at least three such compilers lying around the
place.

They will ALL run under an emulation layer. You know this, and you
are just lying (making people believe you are just naive)

>And no it doesnt work with
microsoft compilers either.

It does with some Microsoft compilers. For example, MSVC1.5x.

All Microsoft DOS compilers run under the EMULATION LAYER of Win32!

Yes, I can run under VISTA 64 a windows 98 virtual machine with
a MSDOS emulation and I can generate code for msdos.

SO WHAT?

Does that mean that I can use those assembler sequences to set the
screen under vista 64?

<snip>

>And
another thing, why is that company moving from one unsupported OS to
another unsupported OS?

Possibly because they want stability. There are still people around who
prefer not to fix something that isn't broken or, if it *is* broken, want
to apply the minimum fix possible. That's their decision, not ours.

Obviously when you praise windows 98 stability you know what you are
talking about :-)


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Nick Keighley]

please don't top-post. Post your reply after the text
you are replying to. I have fixed your post.

On Jun 3, 11:47*pm, Eddie <nos...@nospam. comwrote:>

On Tue, 03 Jun 2008 22:39:37 +0200, jacob navia wrote:

Eddie wrote:

[Eddie wants to write directly to video memory,
Jacob explains he can't]

But shouldn't it work as it is? I think on Microsoft it will work.

No it will NOT work under Microsoft. Under Win32 you can't access video
memory like that.

Could you provide some sample code of changing the color to blue with
textbackground?

#include <tconio.h>
.....

textbackground( BLUE);

Please just read the doc for that function, available in the help
tab of the menu

Thanks for the information, that seems quite simple. Is BLUE an integer
constant? Maybe I can save some space on my source files by just using the
integer value.

HOW? I don't see how it saves even text space. And if your disk
can't spare, say, 10 bytes you *really* have a problem.

I think it would still be better if lcc-win supported writing directly to
video memory as well as using #tconio, this would make it much easier
when porting applications.

why not get a copy of an open-source compiler (eg. gcc) and modify
it yourself. Then you'll find out how easy it is...
--
Nick Keighley

[santosh]

Eddie wrote:

Look, not all companies can afford to spend a fortune on expensive
Vista licenses. We're upgrading to Win98 because the people in our
office really complained about DOS, no one like text-only machines any
more, but probably they just want to be able to play Freecell in their
coffee breaks... and we were able to get a load of Win98 licenses
cheaply.

Actually we decided to go with lcc-win because it's free, but it would
really be an advantage if it could compile for DOS as well during the
changeover. No one has yet answered the question whether there's a DOS
version of lcc-win, or if there are any plans to create one?

You might find better reception if you don't top-post. Anyway, coming to
your question, can you run your application under a DOS prompt in
Windows 98? That way you need not make major changes to your program
and your users can still use Windows 98 for other tasks.

If you must port your program to 32 bits Windows API then there are ways
under Windows 98 to still access the video memory, but the details are
beyond the scope of this group and the technique will not work with
later Windows versions. Please ask for further details in a Windows
programming group like comp.os.ms-windows.program mer.win32.

Coming to your last question it's very unlikely that lcc-win will ever
compiler 16 bit code. You can consider other compilers like Turbo C or
early versions of Borland and Microsoft compilers. Also Watcom C can
generate both 16 and 32 bit code.

<snip>

[Serve Lau]

"Eddie" <no****@nospam. comschreef in bericht
news:pa******** *************** *****@nospam.co m...

Look, not all companies can afford to spend a fortune on expensive Vista
licenses. We're upgrading to Win98 because the people in our office really
complained about DOS, no one like text-only machines any more, but
probably they just want to be able to play Freecell in their coffee
breaks... and we were able to get a load of Win98 licenses cheaply.

Actually we decided to go with lcc-win because it's free, but it would
really be an advantage if it could compile for DOS as well during the
changeover. No one has yet answered the question whether there's a DOS
version of lcc-win, or if there are any plans to create one?

I dont know if there was one but Im sure there are no plans to create one.
Is the original program going to change btw or will it just stay text based?
If it stays that way try to use the old compiler that you were using....

[Serve Lau]

"Richard Heathfield" <rj*@see.sig.in validschreef in bericht
news:Ru******** *************** *******@bt.com. ..

Aha! We are talking about different things, which may explain why we seem
to be disagreeing with each other. I was not intending to claim that
lcc-win should be modified to do what the OP wants (although it *is*
possible, but only at the expense of expanding lcc-win's remit to
incorporate 16-bit code generation, which isn't ever going to happen if
I'm any judge). Rather, I was trying to point out that the OP's overall
objective - that of using direct screen video writing techniques in
programs destined to be executed in a Win98 environment - is achievable,
if he is prepared to migrate to a compiler that supports such techniques.
And such compilers *do* exist.

A long discussion and in the end we are all right. I feel warm and fuzzy
inside now
It's indeed lots easier to use a real dos compiler (although that compiler
might not support that same asm syntax and he will still have to rewrite it
oh noes!) but I'm wondering why he doesnt stay with the old compiler then