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