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.

 

[Lew Pitcher]

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 [snip]
But this doesn't work.

Does anyone have any suggestions?

How about emailing your question directly to the authors of lcc-win? Since
your question doesn't relate to the features found in the C language, but
instead is about an lcc-win specific extension to the language, your best
bet is to take your question to the author.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[jacob navia]

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.

This will not work under windows 98. You need to use the textbackground
library provided by lcc-win.

You will find the documentation for this function in the IDE (wedit) with:
Menu->Help->Standard Library->textbackground.

You should add the tcconio.lib library to the link step.

 

[Flash Gordon]

jacob navia wrote, On 03/06/08 19:38:

You should add the tcconio.lib library to the link step.

You should also take any further discussion to comp.compilers.lcc as it
is completely implementation specific.

 

[Eddie]

OK thanks.

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

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

Thanks.

 

[jacob navia]

OK thanks.

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

 

[Eddie]

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.

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.

 

[Walter Roberson]

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.

 

[jacob navia]

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.

 

[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.

 

[Ian Collins]

Eddie wrote:

[off topic stuff]

Please stop

a) top-posting and

b) posting off topic comments that belong elsewhere.

 

[Serve Lau]

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?

 

[jacob navia]

Serve Lau said:


Do you?

He knows more than you apparently.

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!

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)

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?

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

 

[Nick Keighley]

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


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

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...

 

[Serve Lau]

Do you?
yes

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.

What he asked is not possible.This is what he asked:

"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"

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


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

There we go, get a copy of that compiler then, problem solved. Expect a
bunch of new problems though.

My point was there are no win32 compilers that can do this, not microsoft
borland lccwin32 or whatever.
Yes, there are compilers that can produce 16-bit DOS code, but its still
silly to ask for a full win32 compiler to start producing 16bit dos
executables so you can access video memory directly. Just get a copy of
either an old MS or borland compiler or find a still current 16-bit dos
compiler

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.

Yes for stability windows98 is the obvious choice.

 

[Serve Lau]

You will, I hope, forgive me for disagreeing.

So somebody who compiles 16-bit assembler code with a full win32 compiler
and finds it doesnt work and then starts shouting "bug in compiler" knows
what he's talking about. You dont have too many insights yourself lol.

 

[jacob navia]

Fine - I agree that when compilers are generating 32-bit Windows code,
they're not going to be able to do what the OP wants.

OK then, better late than never.

You acknowledge that what I was saying all along is true.

 

[Eddie]

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?

 

[Serve Lau]

I think you've lost the plot. I suggest you read my articles more
carefully
in future.

there's only one who lost it and thats you

 

[santosh]

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.programmer.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>