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]

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]

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]

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]

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]

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]

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]

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]

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.
--
"To all, to each! a fair good-night,
And pleasing dreams, and slumbers light" -- Sir Walter Scott

[jacob navia]

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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[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.programmer or perhaps
comp.os.ms-windows.programmer.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.com...

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

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

>>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 <[e-mail]:>

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

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>Serve Lau said:

<snip>

>>>
Obviously you dont know what you're talking about.

Do you?

He knows more than you apparently.

You will, I hope, forgive me for disagreeing.

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

Yes.

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

So what? Have you never heard of cross-compilation? I have several
compilers that can generate DOS executables that will run perfectly well
under Windows 98.

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

Right. My point exactly. (And in fact Windows 98, which is the version of
Windows under discussion, is firmly based on MS-DOS.)

So what?

So it is possible for the OP to achieve his objective, that's what.

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

So what? Consider the "as if" rule that we set so much store by, here in
comp.lang.c - it is possible to write a program that executes correctly in
a Win32 environment despite using the same techniques to write to video
RAM that were used under MS-DOS - the fact that an emulator is involved is
likely to trouble the OP not one jot.

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

So what? As long as it works.

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

Right, which is why you need a 16-bit compiler, which is what I said
before. You appear to be violently agreeing with me.

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

Right.

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

You can, if you're running an emulator that faithfully mimics MS-DOS.

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

They will ALL run under an emulation layer.

Right (although the situation may not be quite so clear-cut under Windows
98, which is the OS that the OP is concerned about).

You know this,

Right.

and you are just lying (making people believe you are just naive)

If I have made a mistake in anything I've written in this thread, okay,
I've made a mistake, but please be kind enough to point the mistake out,
because I can't find one. But please drop your imbecilic accusations of
deceit. You don't seem to understand the difference between "disagreeing
with Jacob Navia" and "lying". It is a very important difference.

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

MS compilers that were written for MS-DOS run just fine in MS-DOS. They
*also* work just fine in an emulation layer. MS-DOS compilers that were
written for Win32 but which can generate MS-DOS executables on request
will run just fine under native Win32, and the executables that they
generate will run just fine under emulation. Again, I reiterate that the
situation is not quite as clear-cut under Win98, because it is so firmly
based on MS-DOS that it may not be entirely accurate to say that an
emulation layer is required. And of course Win98 is the OS that the OP is
interested in.

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?

So the OP can achieve his objective, that's what.

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

Yes. If the emulation layer can do it, it can be done - via emulation.
Note, too, that Vista 64 is very different to Windows 98.

><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 :-)

Well, it was certainly more stable than both its predecessor and its
successor. But what I was talking about was a more general kind of
stability - getting the maximum benefit from a minimal change. If you're
currently stuck in MS-DOS-Land, an upgrade to Windows 98 does make a
twisted kind of sense.

You do your reputation, such as it is, no good whatsoever by parading your
ignorance and arrogance in this way. I recommend that, next time, you
think before you post.

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

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

>Obviously you dont know what you're talking about.

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.

>And no it doesnt work with
microsoft compilers either.

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

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

Yes for stability windows98 is the obvious choice.

[Richard Heathfield]

Serve Lau said:

>
"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:lJ*********************@bt.com...

>>Obviously you dont know what you're talking about.

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"

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.

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

There we go, get a copy of that compiler then, problem solved.

Right.

Expect a bunch of new problems though.

Such as?

My point was there are no win32 compilers that can do this, not microsoft
borland lccwin32 or whatever.

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. I don't think the OP
cares about that, just so long as (a) he knows that they can't (to avoid
wasting time on them) and (b) he learns that what he wants *can* be done,
if he's prepared to move to a compiler that allows it.

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

I'm not completely up to date with Borland, but last time I checked, the
Borland C compiler could produce both 16-bit and 32-bit code.

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

Yes for stability windows98 is the obvious choice.

<sighFor stability of *process*, minimum change is the obvious choice. It
might not always be the right choice, but it *is* obvious. In fact, in
this case, minimum change would be DOS->Win95, and instead the OP is
opting for DOS->Win98, which is a better route than either DOS->Win95 or
DOS->WinME. Converting your entire DOS code base to 32-bit Windows is
likely to invite far more problems than you appear to realise.

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

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

>>Do you?

He knows more than you apparently.

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.

[Richard Heathfield]

Serve Lau said:

>
"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:UP******************************@bt.com...

>>>Do you?
He knows more than you apparently.

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.

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

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

>
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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[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?
On Wed, 04 Jun 2008 10:25:40 +0200, Serve Lau wrote:

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

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

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

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

[Serve Lau]

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

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

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

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

Some of what you said is correct, and some of what you said is incorrect
(for example: "It is NOT possible under win32 to access video memory in
the old DOS way!" is incorrect as stated, because it *is* possible - maybe
not in the way you envisage, but it *can* be done, either via an emulation
layer or through using a sufficiently old version of win32, such as
Win98).

Where you have been correct, I have agreed with you. Where you have been
incorrect, I have disagreed with you. If you would like to learn
something, therefore, I suggest that you read the parts of this discussion
where I disagreed with you.

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

[CBFalconer]

Eddie wrote:

>

.... snip ...

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

If you want free, capable of generating DOS programs, and close to
C90 compatibility, try Borlands TC2. It is available on their
page. It runs quite happily under W98.

Using that and gcc for the DJGPP system you have a complete set of
compilers available.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)
<http://members.fortunecity.com/nnqweb/ (newusers)

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

Thanks for the reply. Could you explain the technique you mentioned for
accessing video memory on Win 98?

It's a shame if lcc-win refuses to make a DOS version. Of course Vista and
64-bit and the rest of it has all the hype at the moment, but in terms of
userbase there are millions and millions of DOS/16-bit Windows
installations out there, and I think this would be a much better market to
target than the latest fads from Microsoft. Just my $0.02.

On Wed, 04 Jun 2008 17:54:24 +0530, santosh wrote:

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

[Keith Thompson]

Eddie <no****@nospam.comwrites:

Thanks for the reply. Could you explain the technique you mentioned for
accessing video memory on Win 98?

It's a shame if lcc-win refuses to make a DOS version. Of course Vista and
64-bit and the rest of it has all the hype at the moment, but in terms of
userbase there are millions and millions of DOS/16-bit Windows
installations out there, and I think this would be a much better market to
target than the latest fads from Microsoft. Just my $0.02.

[snip]

Please stop top-posting. Read the following:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

If you want to discuss issues specific to lcc-win, please post to
comp.compilers.lcc or contact jacob navia directly. If you want to
discuss Windows or DOS, please post to an appropriate system-specific
newsgroup.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[David Tiktin]

On 04 Jun 2008, Eddie <no****@nospam.comwrote:

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,

[snip]

If you're referring to lcc-win32, check again:

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

It's not free for commercial use. As you indicate you're working for a
company, I suspect this may apply to you.

Dave

--
D.a.v.i.d T.i.k.t.i.n
t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m

[jacob navia]

David Tiktin wrote:

On 04 Jun 2008, Eddie <no****@nospam.comwrote:

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

[snip]

If you're referring to lcc-win32, check again:

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

It's not free for commercial use. As you indicate you're working for a
company, I suspect this may apply to you.

Dave

You remember that song?

LET IT BE.

If I do not protest why should you?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

David Tiktin wrote:

>On 04 Jun 2008, Eddie <no****@nospam.comwrote:

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

[snip]
If you're referring to lcc-win32, check again:
http://www.cs.virginia.edu/~lcc-win32/
It's not free for commercial use. As you indicate you're working
for a company, I suspect this may apply to you.
Dave

You remember that song?

LET IT BE.

If I do not protest why should you?

I saw no "protest".

Eddie apparently thought that lcc-win is "free". David provided him
with some additional information, namely that it's not entirely free.
Why on Earth would you have a problem with that?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Walter Roberson]

In article <48**************@nospam.com>,
jacob navia <ja***@nospam.orgwrote:

>David Tiktin wrote:

>On 04 Jun 2008, Eddie <no****@nospam.comwrote:

>>Actually we decided to go with lcc-win because it's free,

>If you're referring to lcc-win32, check again:
http://www.cs.virginia.edu/~lcc-win32/
It's not free for commercial use.

>You remember that song?

>LET IT BE.

>If I do not protest why should you?

Although it is not always -obvious- in clc, there are those here
who also earn their living (directly or indirectly) based upon
software licensing fees.

That includes fees that might vary depending upon the commercial vs
non-commercial use. For example, the organization I work for sometimes
has reduced fees for academic use; such is not uncommon when one is
funded by research grants, and we often collaborate with universities,
gaining technology from them in return for sharing our efforts.

But since we do at least partly earn our living from license fees,
we are harmed if the general public starts assuming that free to
one target group means free to everyone, and thus goes ahead and
commercially uses software that is not free for commercial use.

It is of course up to you as to how much (if anything) you ask Eddie to
pay for his commercial use of your product, but it is not good for
the industry if you say "If I do not protest why should you?": that
tends to encourage people to use software beyond the license terms
to the extent that they can "get away with it". And you have to be
careful: if you willingly "turn a blind eye" to a commercial company
using your licensed product without paying, then you could find that
you have lost your rights to enforce your contract terms, just the
same way that trademark holders can lose their rights to their
trademarks if they do not actively enforce ownership.

I would thus suggest that it would be better, both generally and
specifically, if you were to remind Eddie that the software is *not*
free for non-commercial use, and that his business needs to enter
into negotiation with you about its usage of your product. You might
choose to allow his business to not pay you any money for the use
of the product, but you should (IMHO) enter into a written agreement
with Eddie as to the limits of that no-cost use. For example, if
Eddie were to give -me- a copy of lcc-win, could I then use it for
commercial purposes? If he does not recognize the commercial usage
restrictions, then he could, after all, sub-license it to me; presumably
you do not wish to allow that kind of thing.
--
"What is important, then, is not that the critic should possess a
correct abstract definition of beauty for the intellect, but a
certain kind of temperament, the power of being deeply moved by
the presence of beautiful objects." -- Walter Pater

[Antoninus Twink]

On 5 Jun 2008 at 22:20, Keith Thompson wrote:

jacob navia <ja***@nospam.comwrites:

>You remember that song?

LET IT BE.

If I do not protest why should you?

I saw no "protest".

Eddie apparently thought that lcc-win is "free". David provided him
with some additional information, namely that it's not entirely free.
Why on Earth would you have a problem with that?

I understood Jacob's message to be one of resignation. He accepts that
the way of the world is that there will be dishonest people who download
his software and use it commercially without buying a license.

Given that Eddie works for a company that's so cheap-skate that it buys
old Windows 98 licenses to save money, would there really be any point
in trying to enforce lcc-win's license and squeeze some cash out of
them? If it came to that, they'd probably just move to another compiler
that /is/ free.

[Walter Roberson]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>Given that Eddie works for a company that's so cheap-skate that it buys
old Windows 98 licenses to save money, would there really be any point
in trying to enforce lcc-win's license and squeeze some cash out of
them? If it came to that, they'd probably just move to another compiler
that /is/ free.

In a legal sense, Yes, there would be a point. Even if the amount
agreed upon was a token $1 for 5 years of unlimited use within the
company, the attempt to enforce the right -does- make a difference
to future rights enforcement.

--
"MAMA: Oh--So now it's life. Money is life. Once upon a time freedom
used to be life--now it's money. I guess the world really do change.
WALTER: No--it was always money, Mama. We just didn't know about it."
-- Lorraine Hansberry

[jacob navia]

Walter Roberson wrote:

In article <48**************@nospam.com>,
jacob navia <ja***@nospam.orgwrote:

>David Tiktin wrote:

>>On 04 Jun 2008, Eddie <no****@nospam.comwrote:

>>>Actually we decided to go with lcc-win because it's free,

>>If you're referring to lcc-win32, check again:
http://www.cs.virginia.edu/~lcc-win32/
It's not free for commercial use.

>You remember that song?

>LET IT BE.

>If I do not protest why should you?

Although it is not always -obvious- in clc, there are those here
who also earn their living (directly or indirectly) based upon
software licensing fees.

That includes fees that might vary depending upon the commercial vs
non-commercial use. For example, the organization I work for sometimes
has reduced fees for academic use; such is not uncommon when one is
funded by research grants, and we often collaborate with universities,
gaining technology from them in return for sharing our efforts.

But since we do at least partly earn our living from license fees,
we are harmed if the general public starts assuming that free to
one target group means free to everyone, and thus goes ahead and
commercially uses software that is not free for commercial use.

This is correct and if I had a big organization I would
pursue Eddie. But I haven't. And it is a matter of being
practical. As Mr Twink said, if they are trying to buy
cheap licenses of 98 to spare money of buying an XP license,
I do not think they would hesitate a second to drop my
compiler if I would ask them even a token amount.

It is of course up to you as to how much (if anything) you ask Eddie to
pay for his commercial use of your product, but it is not good for
the industry if you say "If I do not protest why should you?": that
tends to encourage people to use software beyond the license terms
to the extent that they can "get away with it". And you have to be
careful: if you willingly "turn a blind eye" to a commercial company
using your licensed product without paying, then you could find that
you have lost your rights to enforce your contract terms, just the
same way that trademark holders can lose their rights to their
trademarks if they do not actively enforce ownership.

I would thus suggest that it would be better, both generally and
specifically, if you were to remind Eddie that the software is *not*
free for non-commercial use, and that his business needs to enter
into negotiation with you about its usage of your product. You might
choose to allow his business to not pay you any money for the use
of the product, but you should (IMHO) enter into a written agreement
with Eddie as to the limits of that no-cost use. For example, if
Eddie were to give -me- a copy of lcc-win, could I then use it for
commercial purposes? If he does not recognize the commercial usage
restrictions, then he could, after all, sub-license it to me; presumably
you do not wish to allow that kind of thing.

In principle you are right. Practically I can't pursue Eddie,
and even I helped him out in his efforts.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Eddie]

Jacob,

Please don't drag my name through the mud. Your compiler was recommended
to me as a free alternative to Microsoft, and I downloaded it for free
from your website - I hadn't read the license closely enough to realize
that it wasn't just pure freeware.

It's true that my company is a low-cost operation - that's what lets us
keep our premiums low for our customers - but we take our legal
responsibilies seriously. Could you confirm that your messages in this
thread are intended as an agreement for us to use your software without
charge?

Actually, a DOS version of your compiler would be very helpful to my
company, so we'd be prepared to fund its development. We'd pay up to $50
per license if you make a DOS version as close as possible to the Windows
version (initially we'd want two licenses, with the possibility of a third
to follow).
On Fri, 06 Jun 2008 01:46:51 +0200, jacob navia wrote:

Walter Roberson wrote:

>In article <48**************@nospam.com>,
jacob navia <ja***@nospam.orgwrote:

>>David Tiktin wrote:
On 04 Jun 2008, Eddie <no****@nospam.comwrote:

>>>>Actually we decided to go with lcc-win because it's free,

>>>If you're referring to lcc-win32, check again:
http://www.cs.virginia.edu/~lcc-win32/
It's not free for commercial use.

>>You remember that song?

>>LET IT BE.

>>If I do not protest why should you?

Although it is not always -obvious- in clc, there are those here
who also earn their living (directly or indirectly) based upon
software licensing fees.

That includes fees that might vary depending upon the commercial vs
non-commercial use. For example, the organization I work for sometimes
has reduced fees for academic use; such is not uncommon when one is
funded by research grants, and we often collaborate with universities,
gaining technology from them in return for sharing our efforts.

But since we do at least partly earn our living from license fees,
we are harmed if the general public starts assuming that free to
one target group means free to everyone, and thus goes ahead and
commercially uses software that is not free for commercial use.

This is correct and if I had a big organization I would
pursue Eddie. But I haven't. And it is a matter of being
practical. As Mr Twink said, if they are trying to buy
cheap licenses of 98 to spare money of buying an XP license,
I do not think they would hesitate a second to drop my
compiler if I would ask them even a token amount.

>It is of course up to you as to how much (if anything) you ask Eddie to
pay for his commercial use of your product, but it is not good for
the industry if you say "If I do not protest why should you?": that
tends to encourage people to use software beyond the license terms
to the extent that they can "get away with it". And you have to be
careful: if you willingly "turn a blind eye" to a commercial company
using your licensed product without paying, then you could find that
you have lost your rights to enforce your contract terms, just the
same way that trademark holders can lose their rights to their
trademarks if they do not actively enforce ownership.

I would thus suggest that it would be better, both generally and
specifically, if you were to remind Eddie that the software is *not*
free for non-commercial use, and that his business needs to enter
into negotiation with you about its usage of your product. You might
choose to allow his business to not pay you any money for the use
of the product, but you should (IMHO) enter into a written agreement
with Eddie as to the limits of that no-cost use. For example, if
Eddie were to give -me- a copy of lcc-win, could I then use it for
commercial purposes? If he does not recognize the commercial usage
restrictions, then he could, after all, sub-license it to me; presumably
you do not wish to allow that kind of thing.

In principle you are right. Practically I can't pursue Eddie,
and even I helped him out in his efforts.

[Cromulent]

On 2008-06-06 16:25:47 +0100, Eddie <no****@nospam.comsaid:

Could you confirm that your messages in this
thread are intended as an agreement for us to use your software without
charge?

Where did he say that?

What he said was he was unable to pursue you. In no way did he give you
permission to use it commercially. That is a very big legal difference.
--
"I disapprove of what you say, but I'll defend to the death your right
to say it." - Voltaire

[Eddie]

He implied it when he said "Let it be", and that it didn't bother him.

However, I have to say that his behavior in this forum has been completely
unprofessional, and as a result I'm going to take my business elsewhere.
Microsoft or Borland would never ignore customer feedback like lcc-win
seems to - there's still been no clear answer about licensing arrangements
or the possibility of a DOS version of lcc-win.
On Fri, 06 Jun 2008 18:16:31 +0100, Cromulent wrote:

On 2008-06-06 16:25:47 +0100, Eddie <no****@nospam.comsaid:

> Could you confirm that your messages in this
thread are intended as an agreement for us to use your software without
charge?

Where did he say that?

What he said was he was unable to pursue you. In no way did he give you
permission to use it commercially. That is a very big legal difference.

[Keith Thompson]

Eddie <no****@nospam.comwrites:

He implied it when he said "Let it be", and that it didn't bother him.

However, I have to say that his behavior in this forum has been completely
unprofessional, and as a result I'm going to take my business elsewhere.
Microsoft or Borland would never ignore customer feedback like lcc-win
seems to - there's still been no clear answer about licensing arrangements
or the possibility of a DOS version of lcc-win.

Have you tried contacting jacob navia, the maintainer, directly?

BTW, please don't top-post. See:
http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Paul Hsieh]

Just to piss people off I am going to top post a pre-amble here.
There have been a *LOT* of wrong things said in this "off-topic"
thread. So I thought I might chime in.

On Jun 4, 6:05 am, Richard Heathfield <[e-mail]:

jacob navia said:

Richard Heathfield wrote:

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.

Some of what you said is correct, and some of what you said is incorrect
(for example: "It is NOT possible under win32 to access video memory in
the old DOS way!" is incorrect as stated, because it *is* possible - maybe
not in the way you envisage, but it *can* be done, either via an emulation
layer or through using a sufficiently old version of win32, such as
Win98).

Win32 is an execution mode invented by Microsoft in the late 80s or
early 90s. It *CANNOT* execute 16-bit code, and it does not emulate
the screen as a VGA interface. You are confusing it with v86 mode
which is a 16 bit DOS (and sometimes DPMI) emulation mode (which does
emulate a VGA interface as well). The two program environment modes
are distinguished at program-load time by the format of the
executable.

Where you have been correct, I have agreed with you. Where you have been
incorrect, I have disagreed with you.

Sort of. You've said a few incorrect things as well.

[...] If you would like to learn
something, therefore, I suggest that you read the parts of this discussion
where I disagreed with you.

You have to be kidding me. Who writes a Win32 compiler and is
unfamiliar with the basic execution modes of Windows? Do you really
think you said something jacob is not aware of? At *best* you guys
are having a communications breakdown. But more likely you see this
and are constructing this contrary point of view out of thin air as
part of some vendetta you have against him.

Let us actually try to help to OP (Eddie):

1. To compile and execute 16 assembly code in the manner you wish, you
need a 16-bit DOS compiler, of which there are many to choose from:
Turbo-C, a very old Microsoft C or "Quick C", Watcom C, Pacific C and
you need to run in a DOS compatible environment (such as MSDOS,
FreeDOS, Win 9X, Win3.1X, Win NT/XP32). lcc-win32, as the name
suggests does not produce 16 bit DOS compatible code.

2. It is possible to port your code to 32-bit DPMI assembly. The
interrupt *pattern* has a direct correspondence with the 16-bit
assembly code you wrote, but its got a lot of extra wrapper overhead.
If you do so, through a very complicated process, you *CAN* use a
win32 compiler (likely even lcc-win32 -- I don't know if it supports
in-line assembly or if its object format is OMF or some other
recognized standard) so long as you *LINK* it with a linker that can
produce a DOS-extended 32 bit application. The only linker I am aware
of that is that powerful and generic is the one that comes with Watcom
C/C++. I think they have retained this capability in "Open Watcom".
But if you are going to go to this much trouble, you might as well
just use the 32-bit DOS compiler that Watcom comes with in the first
place.

3. What Jacob is alluding to with the Vista 64 comment is the fact
that all of the 64-bit flavors of Windows (XP64, Vista64 and
Server2008/64 off the top of my head) do not natively support 16-bit
DOS except by special emulation (via VMWare, Virtual PC, or Hyper/V).
Similarly, you can do so with WINE under Linux. But this is all
besides the point.

4. If all you want to do is to be able to write text on a free
compiler with special colors, you can probably use lcc-win32 with the
standard Windows libraries. There is a console API for Windows
(though I am not familiar with it) and there is the API that Jacob is
suggesting that works in lcc-win32. Heck, there are even ways of
doing this using Direct X which you can program in either Win32 or
AMD64.

5. There are a few more choices amongst "free compilers" available to
you if you wish to program in Win32. Namely: Open Watcom, gcc, and
Microsoft Visual Studio Express. Open Watcom has the advantage that
it supports 16-bit DOS, 32-bit DOS and 32-bit Windows. Unfortunately,
it does not yet support 64-bit Windows as far as I know (but it sounds
like you are not concerned about that.) lcc-win32's main advantage,
as I understand it, is that it apparently comes with a very rich set
of extensions to the core C language.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Walter Roberson]

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

>However, I have to say that his behavior in this forum has been completely
unprofessional, and as a result I'm going to take my business elsewhere.
Microsoft or Borland would never ignore customer feedback like lcc-win
seems to - there's still been no clear answer about licensing arrangements
or the possibility of a DOS version of lcc-win.

You posted your proposal to pay for DOS lcc-win development on
what would have been late Friday afternoon in Jacob's timezone.
It is presently late Monday afternoon in Jacob's timezone -- only
about one working day later. There are many large "professional"
companies (including some that you have named) that take much longer
to make decisions and give responses than you have allowed Jacob.
--
"A scientist who cannot prove what he has accomplished,
has accomplished nothing." -- Walter Reisch

[jacob navia]

Eddie wrote:

He implied it when he said "Let it be", and that it didn't bother him.

However, I have to say that his behavior in this forum has been completely
unprofessional, and as a result I'm going to take my business elsewhere.
Microsoft or Borland would never ignore customer feedback like lcc-win
seems to - there's still been no clear answer about licensing arrangements
or the possibility of a DOS version of lcc-win.

Sorry if I missed one post.

I have been incredibly busy with the 64 bit version.

1) Developing a DOS version of lcc-win is around 1 year of work.
It is not feasible to do this for one client.
2) You can use lcc-win professionally if you buy the professional
version for around 30 euros. Not a big deal really.

Excuse me for missing your post, but I do not check this group every
day.

If you have other questions just mail me at my
email address below.

Thanks for your interest in lcc-win
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Keith Thompson said:

Eddie <no****@nospam.comwrites:

>He implied it when he said "Let it be", and that it didn't bother him.

However, I have to say that his behavior in this forum has been
completely unprofessional, and as a result I'm going to take my business
elsewhere.

I couldn't possibly comment.

>Microsoft or Borland would never ignore customer feedback
like lcc-win seems to - there's still been no clear answer about
licensing arrangements or the possibility of a DOS version of lcc-win.

Have you tried contacting jacob navia, the maintainer, directly?

In this very thread, Jacob Navia has already made his position abundantly
obscure.

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

[Cromulent]

On 2008-06-09 17:34:45 +0100, Eddie <no****@nospam.comsaid:

He implied it when he said "Let it be", and that it didn't bother him.

However, I have to say that his behavior in this forum has been completely
unprofessional, and as a result I'm going to take my business elsewhere.
Microsoft or Borland would never ignore customer feedback like lcc-win
seems to - there's still been no clear answer about licensing arrangements
or the possibility of a DOS version of lcc-win.

Professional? You get what you pay for. Oh, wait... that's right you didn't.

Just because he implied he would let it be does not constitute
permission in a legal sense of the word. The license is the document
you need to consult. If it says you do not have permission to use it
commercially then you don't have permission to use it legally until the
license is changed to reflect the new policy. I would have thought that
was pretty obvious.

--
"I disapprove of what you say, but I'll defend to the death your right
to say it." - Voltaire

[Eddie]

Jacob,

Thanks for the reply.

I've spoken to my boss, and we would consider paying up to $500 for a DOS
version of lcc-win (compiler + IDE + debugger) if it could be developed
within 4 to 6 months. For that we'd expect unlimited-use licenses for both
DOS and Windows versions of lcc-win, but you could also sell licenses to
other customers too (my guess is that the DOS version would have a market
of several thousand companies - I don't think there'll be much slowdown in
the use of DOS for the next 10 to 15 years at least).

If interested, contact me by private email.
On Mon, 09 Jun 2008 19:32:42 +0200, jacob navia wrote:

Eddie wrote:

>He implied it when he said "Let it be", and that it didn't bother him.

However, I have to say that his behavior in this forum has been completely
unprofessional, and as a result I'm going to take my business elsewhere.
Microsoft or Borland would never ignore customer feedback like lcc-win
seems to - there's still been no clear answer about licensing arrangements
or the possibility of a DOS version of lcc-win.

Sorry if I missed one post.

I have been incredibly busy with the 64 bit version.

1) Developing a DOS version of lcc-win is around 1 year of work.
It is not feasible to do this for one client.
2) You can use lcc-win professionally if you buy the professional
version for around 30 euros. Not a big deal really.

Excuse me for missing your post, but I do not check this group every
day.

If you have other questions just mail me at my
email address below.

Thanks for your interest in lcc-win

[Serve Lau]

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

Jacob,

Thanks for the reply.

I've spoken to my boss, and we would consider paying up to $500 for a DOS
version of lcc-win (compiler + IDE + debugger) if it could be developed
within 4 to 6 months. For that we'd expect unlimited-use licenses for both
DOS and Windows versions of lcc-win, but you could also sell licenses to
other customers too (my guess is that the DOS version would have a market
of several thousand companies - I don't think there'll be much slowdown in
the use of DOS for the next 10 to 15 years at least).

If interested, contact me by private email.

I hope food prices are low where jacob lives :P 500$ to build a DOS
compiler, IDE and debugger gogogo.