Discussion:
About graph.lib
(too old to reply)
Johann Klammer
2013-02-05 16:09:43 UTC
Permalink
Raw Message
Hello,

I do not know if you know it, but the modesetting is broken(not
implemented) for all modes above 0x105. Also there's some breakage in
the two 1024x786 modes. Is there a reason this is not done, or has just
no one bothered to write it?

If no one has bothered to write it, I'd like to volunteer, as I still
have some old VESA modesetting code on my disk.

This is what I'd like to do(besides modesetting itself):

needed interface changes in graph.h


All the pixel values have to be 32 bits now.
Functions dealing with pixels(colors) have to be changed...

Motivation:
The truecolor modes need at least 3 bytes/pixel

Suggestion:
long is 32 bits in 16 bit and 32 bit models. Documentation does not
mention 64 bit...
use a typedef unsigned long _pixval?
_CurrColor has to be 32 bits

Functions:
setcolor/getcolor need 32 bits(unsigned long?)
getpixel/setpixel.. anything that takes color values


Functions to convert rgb-values to pixel values

Motivation:
RGB modes need that..

Suggestion:
unsigned long _m_pixel(unsigned char r,unsigned char g,unsigned char b);
void _x_pixel(unsigned char *r,unsigned char *g,unsigned char
*b,unsigned long pix);


Changes to the color #defines

Motivation:
They should work for rgb modes, too.

Suggestion:
change the defines for _BLACK.. etc
to something like:
extern unsigned long _glcolors[];
#define _BLACK (_glcolors[0])
with proper pixel values set when modesetting
There already is a extern long _VGA_Colours[ 16 ]; in globals.h
can it be used?


Will this do, is this possible?
It might break binary compatibility...
Marty Stanquist
2013-02-05 19:31:43 UTC
Permalink
Raw Message
Could you clarify the breakage in modes 104h (1024x768x16) and 105h
(1024x768x256). Is this related to true color?

Marty

"Johann Klammer" wrote in message news:keras5$l0v$***@www.openwatcom.org...

Hello,

I do not know if you know it, but the modesetting is broken(not
implemented) for all modes above 0x105. Also there's some breakage in
the two 1024x786 modes. Is there a reason this is not done, or has just
no one bothered to write it?

If no one has bothered to write it, I'd like to volunteer, as I still
have some old VESA modesetting code on my disk.

This is what I'd like to do(besides modesetting itself):

needed interface changes in graph.h


All the pixel values have to be 32 bits now.
Functions dealing with pixels(colors) have to be changed...

Motivation:
The truecolor modes need at least 3 bytes/pixel

Suggestion:
long is 32 bits in 16 bit and 32 bit models. Documentation does not
mention 64 bit...
use a typedef unsigned long _pixval?
_CurrColor has to be 32 bits

Functions:
setcolor/getcolor need 32 bits(unsigned long?)
getpixel/setpixel.. anything that takes color values


Functions to convert rgb-values to pixel values

Motivation:
RGB modes need that..

Suggestion:
unsigned long _m_pixel(unsigned char r,unsigned char g,unsigned char b);
void _x_pixel(unsigned char *r,unsigned char *g,unsigned char
*b,unsigned long pix);


Changes to the color #defines

Motivation:
They should work for rgb modes, too.

Suggestion:
change the defines for _BLACK.. etc
to something like:
extern unsigned long _glcolors[];
#define _BLACK (_glcolors[0])
with proper pixel values set when modesetting
There already is a extern long _VGA_Colours[ 16 ]; in globals.h
can it be used?


Will this do, is this possible?
It might break binary compatibility...
Johann Klammer
2013-02-06 03:23:47 UTC
Permalink
Raw Message
Post by Marty Stanquist
Could you clarify the breakage in modes 104h (1024x768x16) and 105h
(1024x768x256). Is this related to true color?
No, It is related to the number of (text)rows set in the initialization
code. The last row is not usable with outtext. The number of rows is set
to 50 in the modesetting code, but 768/15=51.<something>. Setting it to
48 solves the problem(but other values are possible). See my thread in
the users newsgroup.

using
nrwsp=_BIOS_data(ROWS);
nrws=*nrwsp;

After modesetting to get the BIOSs idea of rows
gets me a 47, so I guess 48 seems to match the BIOS/DOSs Idea of rows.

Not sure if this is supposed to always work, as the modesetting code in
grsvga.c uses hardcoded values. 50 for both 768 yres modes.
Federico Scala
2013-02-06 10:50:05 UTC
Permalink
Raw Message
Post by Johann Klammer
needed interface changes in graph.h
[...]
setcolor/getcolor need 32 bits(unsigned long?)
getpixel/setpixel.. anything that takes color values
I'm afraid this implies checking any existing source for potential loss
of color data ... maybe a safer strategy would be using alternate
versions (e.g. _setcolor32( _grcolor_t ) ).

Any compatibility-breaking change should be subject to appropriate
#ifdef, also: I don't know if it's still the case (and if that matters
nowadays) but I always thougth the graph.h subsystem as a replacement
for the corresponding MS-C API.

-- Legno
Johann Klammer
2013-02-06 13:23:23 UTC
Permalink
Raw Message
Post by Federico Scala
I'm afraid this implies checking any existing source for potential loss
of color data ... maybe a safer strategy would be using alternate
versions (e.g. _setcolor32( _grcolor_t ) ).
I believe the truncation of 16 bit values will not be a problem as long
as you do not use any True color modes... calling functions with
mismatched parameter sizes may be a proble... not entirely sure as I'm
not up to speed on the calling conventions used. This will happen if
people link old object files(compiled against older(=current) graph.h)
with a modified(=proposed) lib.
Post by Federico Scala
Any compatibility-breaking change should be subject to appropriate
#ifdef, also: I don't know if it's still the case (and if that matters
nowadays) but I always thougth the graph.h subsystem as a replacement
for the corresponding MS-C API.
I do not know. That was a little before my time. In that case binary
comp. may be of importance.
Hans-Bernhard Bröker
2013-02-06 13:51:48 UTC
Permalink
Raw Message
Post by Johann Klammer
not up to speed on the calling conventions used. This will happen if
people link old object files(compiled against older(=current) graph.h)
with a modified(=proposed) lib.
And that's exactly what makes such changes an absolute no-go when
extending a library's functionality. If you need to change a data type,
you have to add a new function with a different name.
Johann Klammer
2013-02-06 17:19:59 UTC
Permalink
Raw Message
Post by Hans-Bernhard Bröker
And that's exactly what makes such changes an absolute no-go when
extending a library's functionality. If you need to change a data type,
you have to add a new function with a different name.
Given age and stagnated pace of development, I am just not sure if
someone still cares about any of it.
Hans-Bernhard Bröker
2013-02-06 17:33:02 UTC
Permalink
Raw Message
Post by Johann Klammer
Given age and stagnated pace of development, I am just not sure if
someone still cares about any of it.
Regardless of whether that's actually true, that's no excuse for
botching the upgrade for everybody who still is interested in using it.
API stability is the single most important property of any library
worth having.
Marty Stanquist
2013-05-21 18:53:27 UTC
Permalink
Raw Message
This is true. Graph.lib has a legacy user base that we need to preserve.
Now, I do think that we should develop an upgraded library that uses long
pointers and supports enhanced VESA modes. We should probably preserve the
function names, but this would have to be a new and separate library (e.g.
Graph32.lib). Going forward, what other enhancements (i.e. new functions) do
you think we should consider?

Marty
Post by Johann Klammer
Given age and stagnated pace of development, I am just not sure if
someone still cares about any of it.
Regardless of whether that's actually true, that's no excuse for
botching the upgrade for everybody who still is interested in using it.
API stability is the single most important property of any library
worth having.
Hans-Bernhard Bröker
2013-05-21 20:35:06 UTC
Permalink
Raw Message
Post by Marty Stanquist
This is true. Graph.lib has a legacy user base that we need to preserve.
Now, I do think that we should develop an upgraded library that uses
long pointers and supports enhanced VESA modes.
While I agree that such a library would be nice to have, I'm less
convinced that we are the ones who should be creating it. Nor that
graph.lib is suitable base to start off of.

I would recommend that graph.lib users who want an upgrade path consider
switching to a something like GRX (http://grx.gnu.de) instead. Yes, the
API is different --- it really has to be. But the benefit is that you
gain a _lot_ of portability.
Marty Stanquist
2013-05-22 01:58:10 UTC
Permalink
Raw Message
Post by Marty Stanquist
This is true. Graph.lib has a legacy user base that we need to preserve.
Now, I do think that we should develop an upgraded library that uses
long pointers and supports enhanced VESA modes.
While I agree that such a library would be nice to have, I'm less
convinced that we are the ones who should be creating it. Nor that
graph.lib is suitable base to start off of.

I would recommend that graph.lib users who want an upgrade path consider
switching to a something like GRX (http://grx.gnu.de) instead. Yes, the
API is different --- it really has to be. But the benefit is that you
gain a _lot_ of portability.

---
GRX is a portable C library, which is a big plus, but it's an external
library. Graph.lib, being part of OW, has (or should have) optimized
assembly code, which should make it faster. But this assumption may no
longer be valid. I can see us doing an enhanced graphics library for the
legacy Graph.lib user base, keeping the same function calls, but it might
not make sense doing this in assembly code. Are embedded 80186 and 80386
processors now able to do reasonable graphics in optimized C?

Marty
Hans-Bernhard Bröker
2013-05-22 22:50:22 UTC
Permalink
Raw Message
Post by Marty Stanquist
GRX is a portable C library, which is a big plus, but it's an external
library. Graph.lib, being part of OW, has (or should have) optimized
assembly code, which should make it faster.
External libraries can have optimized assembly code in them, too.

The only unique advantage an internal OW library might have would have
to result from it being integrated with the code generator itself. I
don't believe graph.lib has any such built-ins functions (a.k.a.
intrinsics), and I doubt it would be worth trying to implement any ---
graphics handling is too dependent on run-time state for that to pay off.
Post by Marty Stanquist
But this assumption may no
longer be valid. I can see us doing an enhanced graphics library for the
legacy Graph.lib user base, keeping the same function calls,
I thought we had already concluded that keeping the function calls the
same can't be done if the enhancement is going to be worth it.
Marty Stanquist
2013-05-23 02:34:31 UTC
Permalink
Raw Message
Post by Marty Stanquist
GRX is a portable C library, which is a big plus, but it's an external
library. Graph.lib, being part of OW, has (or should have) optimized
assembly code, which should make it faster.
External libraries can have optimized assembly code in them, too.

The only unique advantage an internal OW library might have would have
to result from it being integrated with the code generator itself. I
don't believe graph.lib has any such built-ins functions (a.k.a.
intrinsics), and I doubt it would be worth trying to implement any ---
graphics handling is too dependent on run-time state for that to pay off.
Post by Marty Stanquist
But this assumption may no
longer be valid. I can see us doing an enhanced graphics library for the
legacy Graph.lib user base, keeping the same function calls,
I thought we had already concluded that keeping the function calls the
same can't be done if the enhancement is going to be worth it.

--

Sorry, I wasn't clear. I was suggesting that we create a new and separate
library that includes the existing function calls. The existing functions
would behave the same but would now have 32 bit arguments and return values.
For new features and video modes, we would add completely new functions.

Marty
Hans-Bernhard Bröker
2013-05-23 17:37:33 UTC
Permalink
Raw Message
Post by Marty Stanquist
Post by Hans-Bernhard Bröker
I thought we had already concluded that keeping the function calls the
same can't be done if the enhancement is going to be worth it.
Sorry, I wasn't clear. I was suggesting that we create a new and
separate library that includes the existing function calls. The existing
functions would behave the same but would now have 32 bit arguments and
return values.
The problem with that idea is the same as with the original proposal
which started this thread: the existing functions are no longer the
existing functions if you change their types. They're new functions
with the old name, instead. And the only think that's likely to achieve
is serious confusion.
Steve Fabian
2013-05-23 21:47:07 UTC
Permalink
Raw Message
Hans-Bernhard Bröker wrote:
| On 23.05.2013 04:34, Marty Stanquist wrote:
|| "Hans-Bernhard Bröker" wrote in message
|| news:knji3d$apn$***@www.openwatcom.org...
|
||| I thought we had already concluded that keeping the function calls
||| the same can't be done if the enhancement is going to be worth it.
|
|| Sorry, I wasn't clear. I was suggesting that we create a new and
|| separate library that includes the existing function calls. The
|| existing functions would behave the same but would now have 32 bit
|| arguments and return values.
|
| The problem with that idea is the same as with the original proposal
| which started this thread: the existing functions are no longer the
| existing functions if you change their types. They're new functions
| with the old name, instead. And the only think that's likely to
| achieve is serious confusion.

I partially agree (functions with diffferent dynamic range of input or
output are not the same), but I partially disagree. For many functions in
the standard C library argument and value are typed "int" or "unsigned"; the
only property of these types specified in the standard is that they must be
able to uniquely represent 16-bit binary integers. In OW and in many other
compilers, esp. for the Intel architecture, compiler options are used to
select 16b or 32b representation, in some cases having even more bits; all
the functions for a given "word size" are collected into separate sets of
statically or dynamically linkable libraries. according to the size of
"int". This allows a program to be compiled and linked for either 16-b mode
or 32-b mode with no change of source code. It is a method that is viable
for the graphics library as well, and it is what I understand to be what
Marty proposed.
--
Steve
Marty Stanquist
2013-05-24 05:53:27 UTC
Permalink
Raw Message
"Steve Fabian" wrote in message news:knm2ot$udp$***@www.openwatcom.org...

Hans-Bernhard Bröker wrote:
| On 23.05.2013 04:34, Marty Stanquist wrote:
|| "Hans-Bernhard Bröker" wrote in message
|| news:knji3d$apn$***@www.openwatcom.org...
|
||| I thought we had already concluded that keeping the function calls
||| the same can't be done if the enhancement is going to be worth it.
|
|| Sorry, I wasn't clear. I was suggesting that we create a new and
|| separate library that includes the existing function calls. The
|| existing functions would behave the same but would now have 32 bit
|| arguments and return values.
|
| The problem with that idea is the same as with the original proposal
| which started this thread: the existing functions are no longer the
| existing functions if you change their types. They're new functions
| with the old name, instead. And the only thing that's likely to
| achieve is serious confusion.

I partially agree (functions with diffferent dynamic range of input or
output are not the same), but I partially disagree. For many functions in
the standard C library argument and value are typed "int" or "unsigned"; the
only property of these types specified in the standard is that they must be
able to uniquely represent 16-bit binary integers. In OW and in many other
compilers, esp. for the Intel architecture, compiler options are used to
select 16b or 32b representation, in some cases having even more bits; all
the functions for a given "word size" are collected into separate sets of
statically or dynamically linkable libraries. according to the size of
"int". This allows a program to be compiled and linked for either 16-b mode
or 32-b mode with no change of source code. It is a method that is viable
for the graphics library as well, and it is what I understand to be what
Marty proposed.
--
Steve

Right. You wouldn't have to declare and process short integers for the
screen coordinates in 32 bit programs since everything could be of type int.
This would be a big improvement. Since we would now be supporting two
separate libraries and header files (graph.lib/h and graph32.lib/h), we'd
have to do a good job explaining to the user community how and when to use
them. I understand that this could be overwhelming if not done correctly.
But if we proceed, I'll make sure this gets well communicated.

Marty
Marty Stanquist
2013-05-24 06:11:02 UTC
Permalink
Raw Message
"Marty Stanquist" wrote in message news:knmv8n$cp3$***@www.openwatcom.org...

"Steve Fabian" wrote in message news:knm2ot$udp$***@www.openwatcom.org...

Hans-Bernhard Bröker wrote:
| On 23.05.2013 04:34, Marty Stanquist wrote:
|| "Hans-Bernhard Bröker" wrote in message
|| news:knji3d$apn$***@www.openwatcom.org...
|
||| I thought we had already concluded that keeping the function calls
||| the same can't be done if the enhancement is going to be worth it.
|
|| Sorry, I wasn't clear. I was suggesting that we create a new and
|| separate library that includes the existing function calls. The
|| existing functions would behave the same but would now have 32 bit
|| arguments and return values.
|
| The problem with that idea is the same as with the original proposal
| which started this thread: the existing functions are no longer the
| existing functions if you change their types. They're new functions
| with the old name, instead. And the only thing that's likely to
| achieve is serious confusion.

I partially agree (functions with diffferent dynamic range of input or
output are not the same), but I partially disagree. For many functions in
the standard C library argument and value are typed "int" or "unsigned"; the
only property of these types specified in the standard is that they must be
able to uniquely represent 16-bit binary integers. In OW and in many other
compilers, esp. for the Intel architecture, compiler options are used to
select 16b or 32b representation, in some cases having even more bits; all
the functions for a given "word size" are collected into separate sets of
statically or dynamically linkable libraries. according to the size of
"int". This allows a program to be compiled and linked for either 16-b mode
or 32-b mode with no change of source code. It is a method that is viable
for the graphics library as well, and it is what I understand to be what
Marty proposed.
--
Steve

Right. You wouldn't have to declare and process short integers for the
screen coordinates in 32 bit programs since everything could be of type int.
This would be a big improvement. Since we would now be supporting two
separate libraries and header files (graph.lib/h and graph32.lib/h), we'd
have to do a good job explaining to the user community how and when to use
them. I understand that this could be overwhelming if not done correctly.
But if we proceed, I'll make sure this gets well communicated.

Marty

BTW. This is exactly what Microsoft did when they upgraded the Windows GDI
for NT. And yes, it created a lot of confusion. But the porting for the GDI
was not that bad.

Marty
Steve Fabian
2013-05-25 00:58:15 UTC
Permalink
Raw Message
Marty wrote:
| Since we would now be supporting two separate libraries and header files
(graph.lib/h and
| graph32.lib/h)...

Ah! The beauty of it is that we do not NEED separate header files - the same
header file for both graph.lib and graph32.lib suffice, because the compiler
would know what the size of "int" is, but the prototype in the header is the
same.
--
Steve
Javier Gutiérrez
2013-05-26 09:09:10 UTC
Permalink
Raw Message
To me it sounds like having same library for both platforms would keep =

source code mantenability of it easier.
Maybe the risk of broken something is worth, it later fixes and =

performance improvements will be easy to apply.


En Fri, 24 May 2013 08:11:02 +0200, Marty Stanquist <***@att.net> =
=
..
|| "Hans-Bernhard Br=F6ker" wrote in message
|
||| I thought we had already concluded that keeping the function calls=
||| the same can't be done if the enhancement is going to be worth it.=
|
|| Sorry, I wasn't clear. I was suggesting that we create a new and
|| separate library that includes the existing function calls. The
|| existing functions would behave the same but would now have 32 bit
|| arguments and return values.
|
| The problem with that idea is the same as with the original proposal=
| which started this thread: the existing functions are no longer the
| existing functions if you change their types. They're new functions=
| with the old name, instead. And the only thing that's likely to
| achieve is serious confusion.
I partially agree (functions with diffferent dynamic range of input or=
output are not the same), but I partially disagree. For many functions=
in
the standard C library argument and value are typed "int" or "unsigned=
"; =
the
only property of these types specified in the standard is that they mu=
st =
be
able to uniquely represent 16-bit binary integers. In OW and in many =
other
compilers, esp. for the Intel architecture, compiler options are used =
to
select 16b or 32b representation, in some cases having even more bits;=
=
all
the functions for a given "word size" are collected into separate sets=
of
statically or dynamically linkable libraries. according to the size of=
"int". This allows a program to be compiled and linked for either 16-b=
=
mode
or 32-b mode with no change of source code. It is a method that is via=
ble
for the graphics library as well, and it is what I understand to be wh=
at
Marty proposed.
-- =

Usando el cliente de correo de Opera: http://www.opera.com/mail/
Hans-Bernhard Bröker
2013-05-26 17:06:54 UTC
Permalink
Raw Message
Post by Marty Stanquist
Right. You wouldn't have to declare and process short integers for the
screen coordinates in 32 bit programs since everything could be of type int.
No, it can't, because in the existing implementation, that type is not
int, it's short. And that type needs to be changed for _both_ 32-bit
and 16-bit programs. I.e. it would become an alias of uint32_t.

And at that point, the new library is totally incompatible to the old
one, and there's little or nothing to be gained by trying to pretend
otherwise.
Hans-Bernhard Bröker
2013-05-26 17:02:51 UTC
Permalink
Raw Message
Post by Steve Fabian
| The problem with that idea is the same as with the original proposal
| which started this thread: the existing functions are no longer the
| existing functions if you change their types. They're new functions
| with the old name, instead. And the only think that's likely to
| achieve is serious confusion.
I partially agree (functions with diffferent dynamic range of input or
output are not the same), but I partially disagree. For many functions in
the standard C library argument and value are typed "int" or "unsigned";
Let me jump in right there. We're talking about graph.lib here. Its
key argument type that would need changing is that for color
specifications. And that's not int, it's short", i.e. a type that is 16
bits on all supported platforms --- so it can't support 24-bit true
color modes at all. And to make matters worse, it's _signed_ short,
i.e. it will already wreak havoc when used with actual 16-bit modes.

So we would have to completely break API compatibility before we could
even begin thinking about such tricks.

It's essentially a classic pick-any-two situation among

1) binary API compatibility
2) user source code compatibility
3) extended functionality

Currently we're choosing 1 and 2, i.e. no extensions, but 100%
compatibility. But if you want to pick 3, either 1 or 2 will have to go.
r***@hotmail.com
2013-05-27 04:07:21 UTC
Permalink
Raw Message
On Sun, 26 May 2013 14:02:51 -0300, Hans-Bernhard Br=F6ker =
| The problem with that idea is the same as with the original proposa=
l
| which started this thread: the existing functions are no longer the=
| existing functions if you change their types. They're new function=
s
| with the old name, instead. And the only think that's likely to
| achieve is serious confusion.
I partially agree (functions with diffferent dynamic range of input o=
r
output are not the same), but I partially disagree. For many function=
s =
in
the standard C library argument and value are typed "int" or "unsigne=
d";
Let me jump in right there. We're talking about graph.lib here. Its =
=
key argument type that would need changing is that for color =
specifications. And that's not int, it's short", i.e. a type that is =
16 =
bits on all supported platforms --- so it can't support 24-bit true =
color modes at all. And to make matters worse, it's _signed_ short, =
i.e. it will already wreak havoc when used with actual 16-bit modes.
So we would have to completely break API compatibility before we could=
=
even begin thinking about such tricks.
It's essentially a classic pick-any-two situation among
1) binary API compatibility
2) user source code compatibility
3) extended functionality
Currently we're choosing 1 and 2, i.e. no extensions, but 100% =
compatibility. But if you want to pick 3, either 1 or 2 will have to =
go.

OW is OPEN source now. Backward compatibility has value, but only up to =
a
certain level. When it ihibits progress, it has outlived it's use.
IMHO, ditch 1) support 2) to the extent possible and full speed ahead on=
=

3).

Roald
Federico Scala
2013-02-06 18:13:26 UTC
Permalink
Raw Message
Post by Johann Klammer
I believe the truncation of 16 bit values will not be a problem as long
as you do not use any True color modes...
Sure. But older source code will need to be updated to use the new
library to its full power, so using distinct function calls makes it a
little bit clearer.
Post by Johann Klammer
calling functions with
mismatched parameter sizes may be a proble...
A real one, whatever calling convention is used. Separate calls avoid
this. I do not like WIN32 API very much, but they have a strong
tradition of "Ex"tended function versions ...
Post by Johann Klammer
I do not know. That was a little before my time.
I just realized being a jurassic-coder ... ;-)
Post by Johann Klammer
In that case binary comp. may be of importance.
Not really - AFAIK WATCOM library won't link with MS objs anyway.
The whole point, I think, is that the WATCOM graphic library (and other
pieces of WC library) is there for compatibility with older MSC
compilers, and all it needed was to replicate then-current MS
functionality. This is a value to be preserved, since there's no other
active compiler for DOS-like systems that allows that.

New, updated API is welcome, of course. Where technically possible, keep
the original function/type names, otherwise make an extended version of
them. The older functions may also be simple "parameter converters" that
call new ones internally.

-- Legno
Johann Klammer
2013-02-18 23:55:32 UTC
Permalink
Raw Message
Hello,

I have come up with a patch..
It's here:
http://members.aon.at/~aklamme4/scratch/graphlib.patch

Someone with perforce access should probably apply it...
Marty Stanquist
2013-02-19 14:04:16 UTC
Permalink
Raw Message
Thanks. I'm currently reviewing it.

Marty

"Johann Klammer" wrote in message news:kfuf1h$fdp$***@www.openwatcom.org...

Hello,

I have come up with a patch..
It's here:
http://members.aon.at/~aklamme4/scratch/graphlib.patch

Someone with perforce access should probably apply it...
Johann Klammer
2013-02-20 00:47:49 UTC
Permalink
Raw Message
The name mangling for the two added variables is missing.

#pragma aux _coltbl "_*";
#pragma aux _VGANBytes "_*";

needs to be added to asmrefs.h

otherwise there'll be duplicate symbols etc...
Marty Stanquist
2013-02-20 01:15:13 UTC
Permalink
Raw Message
OK, thanks.

Marty

"Johann Klammer" wrote in message news:kg16fj$s26$***@www.openwatcom.org...

The name mangling for the two added variables is missing.

#pragma aux _coltbl "_*";
#pragma aux _VGANBytes "_*";

needs to be added to asmrefs.h

otherwise there'll be duplicate symbols etc...
Javier Gutiérrez
2013-05-20 15:35:15 UTC
Permalink
Raw Message
Any news?

En Tue, 19 Feb 2013 15:04:16 +0100, Marty Stanquist <***@att.net> =
=
Post by Marty Stanquist
Thanks. I'm currently reviewing it.
Marty
I have come up with a patch..
http://members.aon.at/~aklamme4/scratch/graphlib.patch
Someone with perforce access should probably apply it...
-- =

Usando el cliente de correo de Opera: http://www.opera.com/mail/
Marty Stanquist
2013-05-21 18:54:17 UTC
Permalink
Raw Message
Trying to get the 50 column issue duplicating on a real DOS machine. Still
working on it.

Marty

"Javier Gutiérrez" wrote in message news:***@i3-380...

Any news?
Post by Marty Stanquist
Thanks. I'm currently reviewing it.
Marty
I have come up with a patch..
http://members.aon.at/~aklamme4/scratch/graphlib.patch
Someone with perforce access should probably apply it...
--
Usando el cliente de correo de Opera: http://www.opera.com/mail/
Marty Stanquist
2013-05-21 18:59:32 UTC
Permalink
Raw Message
Sorry, meant 50 row issue. :-)

Marty

"Marty Stanquist" wrote in message news:kngfsr$pnf$***@www.openwatcom.org...

Trying to get the 50 column issue duplicating on a real DOS machine. Still
working on it.

Marty

"Javier Gutiérrez" wrote in message news:***@i3-380...

Any news?
Post by Marty Stanquist
Thanks. I'm currently reviewing it.
Marty
I have come up with a patch..
http://members.aon.at/~aklamme4/scratch/graphlib.patch
Someone with perforce access should probably apply it...
--
Usando el cliente de correo de Opera: http://www.opera.com/mail/
Marty Stanquist
2013-06-03 01:34:20 UTC
Permalink
Raw Message
"Johann Klammer" wrote in message news:kfuf1h$fdp$***@www.openwatcom.org...

Hello,

I have come up with a patch..
It's here:
http://members.aon.at/~aklamme4/scratch/graphlib.patch

Someone with perforce access should probably apply it...

I'm getting ready to apply your patch to a copy of graphlib called
graphlib32, also updating the calling arguments and return values to type
int. I also have this up and running in the IDE and will look at the 50 row
issue using the remote debugger. When I get the library fix-up process
working (merge w/ pgchart, rename symbols), I'll apply the patch. You're
right about the test code, it seems inadequate. So I'll look at this as
well. This work will be for evaluation purposes while we're deciding how to
proceed.

Marty

Loading...