Is there a stack version of the Qwin3.lib available for 4.25?
Thanks,
Tony
Tony Williams <twilqnx@yahoo.com> wrote:
Is there a stack version of the Qwin3.lib available for 4.25?
No, there is not. None has ever been created.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
Tony Williams <> twilqnx@yahoo.com> > wrote:
Is there a stack version of the Qwin3.lib available for 4.25?No, there is not. None has ever been created.
So, will you create one if someone need it?
does the standard answer “talk to your sales rep if you want it”
apply here? or the other standard answer “qnx4 is no longer supported” 
“Dmit” <dmit@com.invalid> wrote in message news:bp0h1m$6ls$1@inn.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote:
Tony Williams <> twilqnx@yahoo.com> > wrote:
Is there a stack version of the Qwin3.lib available for 4.25?No, there is not. None has ever been created.
So, will you create one if someone need it?
does the standard answer “talk to your sales rep if you want it”
apply here? or the other standard answer “qnx4 is no longer supported” >
Unless you have a huge pile of money, my feeling is you`d better forget it.
There doesn’t seems to be any business case.
- Mario
\
Dmit <dmit@com.invalid> wrote in message news:bp0h1m$6ls$1@inn.qnx.com…
David Gibbs <> dagibbs@qnx.com> > wrote:
Tony Williams <> twilqnx@yahoo.com> > wrote:
Is there a stack version of the Qwin3.lib available for 4.25?No, there is not. None has ever been created.
So, will you create one if someone need it?
does the standard answer “talk to your sales rep if you want it”
apply here? or the other standard answer “qnx4 is no longer supported” >
QNX4 is supported.
It’s not a simple as 'build it, then give it"; eventually, there are
questions, behaviour differences or even issues with the rebuild and that
means we need to support this new build. For us to support it, we need to
test it before it goes out the door; and you can guess what it means if we
need to test and support something new, it means there needs to be business
case to do so.
Besides, the reason for the stack version was never stated, and I think it’s
worth a shot avoiding the issue and working with released product first.
-Adam
Adam Mallory <amallory@qnx.com> wrote:
It’s not a simple as 'build it, then give it"; eventually, there are
questions, behaviour differences or even issues with the rebuild and that
means we need to support this new build. For us to support it, we need to
test it before it goes out the door; and you can guess what it means if we
need to test and support something new, it means there needs to be business
case to do so.
assuming your source is controlled and you know which source
corresponds the release out there, isn’t that as simple as
changing -3r to -3s in the makefiles, and make? (at least that’s
what I did for having both libs for open source libs such as openssl).
Of course, you can put those out as non-supported. Just as Steve Furr
did for the X11R5 libs, which helped a lot at the same when JC
was testing the gcc for QNX4…
Besides, the reason for the stack version was never stated, and I think it’s
worth a shot avoiding the issue and working with released product first.
there are probably many. Here is one: since QSS has no interest in
helping the Open Watcom project (maybe worth another thread 
,
people sometimes have to use JC’s gcc for something, which only
works for stack libs as far as I know.
Frank
liug <liug@mama.indstate.edu> wrote:
Adam Mallory <> amallory@qnx.com> > wrote:
It’s not a simple as 'build it, then give it"; eventually, there are
questions, behaviour differences or even issues with the rebuild and that
means we need to support this new build. For us to support it, we need to
test it before it goes out the door; and you can guess what it means if we
need to test and support something new, it means there needs to be business
case to do so.assuming your source is controlled and you know which source
corresponds the release out there, isn’t that as simple as
changing -3r to -3s in the makefiles, and make? (at least that’s
If it were a simple library, sure. But it isn’t – QNX Windows uses
a shared library, so this gets a bit messier.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
assuming your source is controlled and you know which source
corresponds the release out there, isn’t that as simple as
changing -3r to -3s in the makefiles, and make? (at least that’sIf it were a simple library, sure. But it isn’t – QNX Windows uses
a shared library, so this gets a bit messier.
You can just provide a static lib for 3s, can’t you?
If I remember correctly, X (sold from QSS) also uses shared lib and
3r only. But Steve Furr can still provide just the static 3s X lib
unsupported.
Frank
liug <liug@mama.indstate.edu> wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
assuming your source is controlled and you know which source
corresponds the release out there, isn’t that as simple as
changing -3r to -3s in the makefiles, and make? (at least that’sIf it were a simple library, sure. But it isn’t – QNX Windows uses
a shared library, so this gets a bit messier.You can just provide a static lib for 3s, can’t you?
In theory yes.
If I remember correctly, X (sold from QSS) also uses shared lib and
3r only. But Steve Furr can still provide just the static 3s X lib
unsupported.
Again, in theory yes.
I haven’t seen a further follow-up from the original requester as
to why they wanted/needed this.
It really comes down to a business case – do I take time away
from something else that needs to be done in order to do this.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs wrote:
liug <> liug@mama.indstate.edu> > wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
assuming your source is controlled and you know which source
corresponds the release out there, isn’t that as simple as
changing -3r to -3s in the makefiles, and make? (at least that’sIf it were a simple library, sure. But it isn’t – QNX Windows uses
a shared library, so this gets a bit messier.You can just provide a static lib for 3s, can’t you?
In theory yes.
If I remember correctly, X (sold from QSS) also uses shared lib and
3r only. But Steve Furr can still provide just the static 3s X lib
unsupported.Again, in theory yes.
I haven’t seen a further follow-up from the original requester as
to why they wanted/needed this.It really comes down to a business case – do I take time away
from something else that needs to be done in order to do this.
David,
We need the stack version of the Windows library so that we don’t have to
maintain 2 versions of our libraries to build our product. The stack
libary requirement is the result of an application within our product that
is being built with a gnu cc built library. That library requires the
stack version calling sequence. We tried converting all of our product
libraries to the stack version, but there were applications that couldn’t
get built when the Windows stack library could not be found.
Without the Windows stack library, we are forced to have a register mode
product library
and a stack mode product library and one or the other library is linked to
an application, depending on its needs. It would be much simplier for us
if we only needed to maintain one product library instead of two.
Does this help to justify reassigning QSSL work to allow a windows stack
library to be built for QNX 4?
Thanks,
Tony
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Tony Williams <twillqnx@yahoo.com> wrote:
David Gibbs wrote:
Again, in theory yes.
I haven’t seen a further follow-up from the original requester as
to why they wanted/needed this.It really comes down to a business case – do I take time away
from something else that needs to be done in order to do this.David,
We need the stack version of the Windows library so that we don’t have to
maintain 2 versions of our libraries to build our product. The stack
libary requirement is the result of an application within our product that
is being built with a gnu cc built library. That library requires the
stack version calling sequence. We tried converting all of our product
libraries to the stack version, but there were applications that couldn’t
get built when the Windows stack library could not be found.Without the Windows stack library, we are forced to have a register mode
product library
and a stack mode product library and one or the other library is linked to
an application, depending on its needs. It would be much simplier for us
if we only needed to maintain one product library instead of two.Does this help to justify reassigning QSSL work to allow a windows stack
library to be built for QNX 4?
Yes and no.
I built one and emailed it to you. As I noted in the email,
“It has not been tested in anyway. This is not released, it is
not beta or alpha, it isn’t even experimental, all it is built.
This is not shippable product.”
So, that’s the easy part. As Adam mentioned, this is not tested or
supported product – so you aren’t licensed to ship it on to your
customers.
I can’t make the decision to justify the cost of testing, verification,
and productization of such a library, that would require working up
a business case.
I would guess, though, that it will be more cost-effective for you to
maintain the parallel versions of your libraries than to have us
productize this library for you.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
I know that this would be a pain in the butt, but if it were
absolutely necessary you could write asm cover functions that go betwen
the stack calling conventions and the register calling conventions.
If you do this, you would have to make sure that you renamed all of the
function names. I.E. stick an “_s” on the end of all of the function
names to indicate the stack calling version.
So, insted of your program calling XYZ(), you would have to call
XYZ_S() and have it call XYZ() after it moves the appropriate objects
into the appropriate registers. Perhaps you could do the renames via
an include file that defines XYZ() AS XYZ_S(). That way you wouldn’t
have to modify all of your source code.
Tony Williams <twillqnx@yahoo.com> wrote:
TW > We need the stack version of the Windows library so that we don’t have to
TW > maintain 2 versions of our libraries to build our product. The stack
TW > libary requirement is the result of an application within our product that
TW > is being built with a gnu cc built library. That library requires the
TW > stack version calling sequence. We tried converting all of our product
TW > libraries to the stack version, but there were applications that couldn’t
TW > get built when the Windows stack library could not be found.
TW > Without the Windows stack library, we are forced to have a register mode
TW > product library
TW > and a stack mode product library and one or the other library is linked to
TW > an application, depending on its needs. It would be much simplier for us
TW > if we only needed to maintain one product library instead of two.
TW > Does this help to justify reassigning QSSL work to allow a windows stack
TW > library to be built for QNX 4?
TW > Thanks,
TW > Tony
Bill Caroselli <qtps@earthlink.net> wrote:
I know that this would be a pain in the butt, but if it were
absolutely necessary you could write asm cover functions that go betwen
the stack calling conventions and the register calling conventions.If you do this, you would have to make sure that you renamed all of the
function names. I.E. stick an “_s” on the end of all of the function
names to indicate the stack calling version.So, insted of your program calling XYZ(), you would have to call
XYZ_S() and have it call XYZ() after it moves the appropriate objects
into the appropriate registers. Perhaps you could do the renames via
an include file that defines XYZ() AS XYZ_S(). That way you wouldn’t
have to modify all of your source code.
It’s a good idea, and can be easier to implement if you go one step
further. Or maybe two steps further.
The first step is to write your cover functions in C rather than
assembly, using the Watcom __cdecl keyword to ask the compiler to use
the stack calling convention:
extern int SomeWinFun( int x, int y ); /* A register-based function */
int __cdecl SomeWinFun_S( int x, int y ) { /* A stack-based equivalent */
return SomeWinFun( x, y );
}
The next step is to notice that since Watcom uses different “name
mangling” rules for stack-based and for register-based functions, it
allows you to get rid of the extra “S". You just need a way to
convince the compiler not to complain about the two functions having the
same name in C. You can do it by changing the pragma that defines the
meaning of __cdecl to not add a "” in front of the function name,
which will allow you to add it yourself in your C code:
/* I just copied this pragma from Watcom docs and replaced “_" with "” /
#pragma aux __cdecl ""
parm caller []
value struct float struct routine [eax]
modify [eax ecx edx]
extern int SomeWinFun( int x, int y );
int __cdecl _SomeWinFun( int x, int y ) {
return SomeWinFun( x, y );
}
This way, any other stack-based module will be able to call your
_SomeWinFun() function as if its real name were SomeWinFun() – which is
exactly what you want.
Now you just need to include the appropriate header instead of declaring
the register-based SomeWinFun() by hand, and write the __cdecl
definitions for all the Windows functions you care about.
Good luck!..
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > Bill Caroselli <qtps@earthlink.net> wrote:
I know that this would be a pain in the butt, but if it were
absolutely necessary you could write asm cover functions that go betwen
the stack calling conventions and the register calling conventions.If you do this, you would have to make sure that you renamed all of the
function names. I.E. stick an “_s” on the end of all of the function
names to indicate the stack calling version.So, insted of your program calling XYZ(), you would have to call
XYZ_S() and have it call XYZ() after it moves the appropriate objects
into the appropriate registers. Perhaps you could do the renames via
an include file that defines XYZ() AS XYZ_S(). That way you wouldn’t
have to modify all of your source code.
WL > It’s a good idea, and can be easier to implement if you go one step
WL > further. Or maybe two steps further.
WL > The first step is to write your cover functions in C rather than
WL > assembly, using the Watcom __cdecl keyword to ask the compiler to use
WL > the stack calling convention:
I didn’t know about this one. This si definitely better.
WL > extern int SomeWinFun( int x, int y ); /* A register-based function */
WL > int __cdecl SomeWinFun_S( int x, int y ) { /* A stack-based equivalent */
WL > return SomeWinFun( x, y );
WL > }
WL > The next step is to notice that since Watcom uses different “name
WL > mangling” rules for stack-based and for register-based functions, it
WL > allows you to get rid of the extra “S". You just need a way to
WL > convince the compiler not to complain about the two functions having the
WL > same name in C. You can do it by changing the pragma that defines the
WL > meaning of __cdecl to not add a "” in front of the function name,
WL > which will allow you to add it yourself in your C code:
WL > /* I just copied this pragma from Watcom docs and replaced “_" with "” /
WL > #pragma aux __cdecl ""
WL > parm caller []
WL > value struct float struct routine [eax]
WL > modify [eax ecx edx]
WL > extern int SomeWinFun( int x, int y );
WL > int __cdecl _SomeWinFun( int x, int y ) {
WL > return SomeWinFun( x, y );
WL > }
WL > This way, any other stack-based module will be able to call your
WL > _SomeWinFun() function as if its real name were SomeWinFun() – which is
WL > exactly what you want.
WL > Now you just need to include the appropriate header instead of declaring
WL > the register-based SomeWinFun() by hand, and write the __cdecl
WL > definitions for all the Windows functions you care about.
WL > Good luck!..
Very clever stuff!