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]

Re: Bug/problem with lcc-win

In comp.lang.c, Eddie wrote:

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]

Re: Bug/problem with lcc-win

Eddie wrote:

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.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Eddie]

Re: Bug/problem with lcc-win

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.


On Tue, 03 Jun 2008 20:38:37 +0200, jacob navia wrote:

Eddie wrote:

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

[jacob navia]

Re: Bug/problem with lcc-win

Eddie wrote:

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
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Flash Gordon]

Re: Bug/problem with lcc-win

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

Eddie wrote:

>Hi
>>
>I am using lcc-win on Windows 98. I'm writing a simple c console app, and

<snip completely unportable code and solution>

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

[CBFalconer]

Re: Bug/problem with lcc-win

Lew Pitcher wrote:

Eddie wrote:
>

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

He can also use comp.compilers. lcc. The point is that none of
those 'words' are defined in the C standard, and are thus off-topic
in c.l.c

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Eddie]

Re: Bug/problem with lcc-win

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.


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

Eddie wrote:

>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

[Walter Roberson]

Re: Bug/problem with lcc-win

In article <pan.2008.06.03 .22.47.46.36389 0@nospam.com>,
Eddie <nospam@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.
--
"To all, to each! a fair good-night,
And pleasing dreams, and slumbers light" -- Sir Walter Scott

[jacob navia]

Re: Bug/problem with lcc-win

Walter Roberson wrote:

In article <pan.2008.06.03 .22.47.46.36389 0@nospam.com>,
Eddie <nospam@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.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Eddie]

Re: Bug/problem with lcc-win

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 <pan.2008.06.03 .22.47.46.36389 0@nospam.com>,
>Eddie <nospam@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]

Re: Bug/problem with lcc-win

Eddie wrote:

[off topic stuff]

Please stop

a) top-posting and

b) posting off topic comments that belong elsewhere.

--
Ian Collins.

[Richard Heathfield]

Re: Bug/problem with lcc-win

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]

Re: Bug/problem with lcc-win


"Eddie" <nospam@nospam. comschreef in bericht
news:pan.2008.0 6.04.08.13.33.2 51038@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]

Re: Bug/problem with lcc-win

Serve Lau said:

>
"Eddie" <nospam@nospam. comschreef in bericht
news:pan.2008.0 6.04.08.13.33.2 51038@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