Re: cygwinb19.dll

Re: cygwinb19.dll

[jurgen.defurne]

Tornado II for VxWorks, the ccmips.exe compiler. But it
could be that the problem lies in a different direction, because
we stopped all cygwin processes, took the directories out
of the path, and we still get an error.

Recompiling IS an option, since we do have the sources,
but not really feasible, because the compiler must be
the same across all worldwide sites. It does work on other
workstations, though. The only difference is that those are
not equipped with Cygwin.

Regards,

Jurgen










Lapo Luchini <lapo@lapo.it>
09/04/2003 01:23 PM

 
        To:     Mailing@smtpscan-nl8.philips.com
"List@smtpscan-nl8.philips.com:CygWin" <cygwin@cygwin.com>
        cc:     Jurgen Defurne/BRG/CE/PHILIPS@EMEA1
        Subject:        Re: cygwinb19.dll
        Classification: 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jurgen.defurne@philips.com wrote:

| Nope, did not work either. Still waiting for info from someone more
| experienced.

The "definitive" solution is of course to recompile the app with latest
cygwin headers *and* dll.
You *should* have the sources anyway... (unless the author bought a
cygwin license from redhat, IANAL at all)

Maybe you can discolse a little more infos so we can try to understand
better the problem?

You said "Tornado from WindRiver" but I find little info on Windriver's
website
<http://www.windriver.com/products/products_by_name_t.html>

- --
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAj9XIKgACgkQaJiCLMjyUvstgwCeI4t4bKMJctar7SRWnbBivqQR
FBcAn1bU2RmEd6CvVQzRtHJVmlWWk/3H
=grtz
-----END PGP SIGNATURE-----






--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jurgen.defurne@philips.com wrote:

| Recompiling IS an option, since we do have the sources, but not
| really feasible, because the compiler must be the same across all
| worldwide sites. It does work on other workstations, though. The only
| difference is that those are not equipped with Cygwin.

Should be the "very same" or just "produce the same output"?
If you recompile the same "cc" sources with a different version of
cygwin library you should definitely get a 'diferent' compiled
ccmips.exe which should nevertheless produce the very same mips code.

And you would "need" to do this only once and use it only on machines
that "have also cygwin".

Anyone can confirm this?

PS: of course if WindRiver used a cygwin release a little less...
"obsolete" it would have been better ^_____^

- --
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAj9XJdgACgkQaJiCLMjyUvvVPwCgtBrbAUPyy98dsH3y8Px6XNgD
IroAoO6rPg+plY1ehRg6pT+IEuLsdrf/
=+50t
-----END PGP SIGNATURE-----



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[Christopher Faylor]

On Thu, Sep 04, 2003 at 01:33:00PM +0200, jurgen.defurne@philips.com wrote:
>Tornado II for VxWorks, the ccmips.exe compiler.  But it could be that
>the problem lies in a different direction, because we stopped all
>cygwin processes, took the directories out of the path, and we still
>get an error.

If you are having problems with software that you received from
WindRiver, you should be contacting WindRiver for help.  This is not a
technical support forum for other company's products.
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[jurgen.defurne]

Sorry,

My colleague created this cygwinb19.dll as a copy from
cygwin1.dll.

Regards,

Jurgen









jurgen.defurne+FromInterNet@philips.com
Sent by: 
cygwin-owner@cygwin.com
11/04/2003 09:14 AM

 
        To:     cygwin@cygwin.com
        cc:     (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
        Subject:        cygwinb19.dll
        Classification: 



Hello,

This is the first time I noticed, when I tried to copy cygwin1.dll,
using filename completion, I noticed that there is also a
cygwinb19.dll. Is this for backwards compatibility with
older programs ?

Regards,

Jurgen

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

cygwinb19.dll

[jurgen.defurne]

Hello,

This is the first time I noticed, when I tried to copy cygwin1.dll,
using filename completion, I noticed that there is also a
cygwinb19.dll. Is this for backwards compatibility with
older programs ?

Regards,

Jurgen

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[Christopher Faylor]

On Thu, Sep 04, 2003 at 04:02:11PM +0200, jurgen.defurne wrote:
>Yes, Christopher, I know.  I was just trying to get some more
>information or maybe a quick fix.  In this case I think it is better
>that the more we know, the better we can defend ourselves against
>people who try make us pay licenses, based upon 5 year old products,
>which have perfectly well successors.

Let me make it really clear again: If you are using software distributed
by some other entity then you go to them for help.  I'm sorry (really!)
that you are having problems but they are not *my* problems to solve and
they are not problems that this mailing list can be used to solve.  It
is unreasonable to expect that a high traffic mailing list like this one
could be used as back channel support for an unrelated release.  It is
also questionable whether discussing a DLL released in 1998 is useful
here either.

No further discussion about this here, please.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[jurgen.defurne]

Yes, Christopher, I know. I was just trying to get some more information
or maybe a quick fix. In this case I think it is better that the more we
know, the better we can defend ourselves against people who try
make us pay licenses, based upon 5 year old products, which have
perfectly well successors.

Regards,

Jurgen










Christopher Faylor <cgf-rcm@cygwin.com>
09/04/2003 03:50 PM
Please respond to cygwin

 
        To:     cygwin@cygwin.com
        cc:     (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
        Subject:        Re: cygwinb19.dll
        Classification: 



On Thu, Sep 04, 2003 at 01:33:00PM +0200, jurgen.defurne@philips.com 
wrote:
>Tornado II for VxWorks, the ccmips.exe compiler.  But it could be that
>the problem lies in a different direction, because we stopped all
>cygwin processes, took the directories out of the path, and we still
>get an error.

If you are having problems with software that you received from
WindRiver, you should be contacting WindRiver for help.  This is not a
technical support forum for other company's products.
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jurgen.defurne@philips.com wrote:

| Nope, did not work either. Still waiting for info from someone more
| experienced.

The "definitive" solution is of course to recompile the app with latest
cygwin headers *and* dll.
You *should* have the sources anyway... (unless the author bought a
cygwin license from redhat, IANAL at all)

Maybe you can discolse a little more infos so we can try to understand
better the problem?

You said "Tornado from WindRiver" but I find little info on Windriver's
website
<http://www.windriver.com/products/products_by_name_t.html>

- --
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAj9XIKgACgkQaJiCLMjyUvstgwCeI4t4bKMJctar7SRWnbBivqQR
FBcAn1bU2RmEd6CvVQzRtHJVmlWWk/3H
=grtz
-----END PGP SIGNATURE-----



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[jurgen.defurne]

Nope, did not work either. Still waiting for info
from someone more experienced.

Regards,

Jurgen










jurgen.defurne+FromInterNet@philips.com
Sent by: 
cygwin-owner@cygwin.com
09/04/2003 01:02 PM

 
        To:     cygwin@cygwin.com
        cc:     (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
        Subject:        Re: cygwinb19.dll
        Classification: 



We renamed the cygwinb19.dll to get it out of the way and copied
the new one into the directory. Now it works.

Jurgen










jurgen.defurne+FromInterNet@philips.com
Sent by: 
cygwin-owner@cygwin.com
09/04/2003 11:15 AM

 
        To:     cygwin@cygwin.com
        cc:     (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
        Subject:        cygwinb19.dll
        Classification: 



Dear all,

We have a product Tornado from WindRiver, which uses cygwinb19.dll.

The Tornado compiler generates an access violation on the workstation
which also happens to run a more recent version of Cygwin. This access
violation takes place in the cygwinb19.dll.

I happen to know from previous discussions that one should not have
several versions of cygwin1.dll in his path. Does the same problem
arise with one version of cygwinb19.dll and one version of cygwin1.dll ?

Regards,

Jurgen

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[jurgen.defurne]

We renamed the cygwinb19.dll to get it out of the way and copied
the new one into the directory. Now it works.

Jurgen










jurgen.defurne+FromInterNet@philips.com
Sent by: 
cygwin-owner@cygwin.com
09/04/2003 11:15 AM

 
        To:     cygwin@cygwin.com
        cc:     (bcc: Jurgen Defurne/BRG/CE/PHILIPS)
        Subject:        cygwinb19.dll
        Classification: 



Dear all,

We have a product Tornado from WindRiver, which uses cygwinb19.dll.

The Tornado compiler generates an access violation on the workstation
which also happens to run a more recent version of Cygwin. This access
violation takes place in the cygwinb19.dll.

I happen to know from previous discussions that one should not have
several versions of cygwin1.dll in his path. Does the same problem
arise with one version of cygwinb19.dll and one version of cygwin1.dll ?

Regards,

Jurgen

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[Brian Dessent]

Lapo Luchini wrote:

> Let's just say that version b19 is "very very very very old" and,
> indeed, obsolete...
> But anyway the new tools shouldn't have problems if a DLL *with a
> different name* is found in the system.
> 
> BT:W notcie that my answer is not authoritative, only CGF and a few of
> other can give those...

If they both try to use some other resource (such as shared memory or a
named pipe or something) that have the same name it'll die a horrible
death.  

The obvious thing would be to try to recompile the app with a recent
build of Cygwin... it should be open source unless they bought a buy-out
license from Redhat, right?

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwinb19.dll

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jurgen.defurne@philips.com wrote:

| I happen to know from previous discussions that one should not have
| several versions of cygwin1.dll in his path. Does the same problem
| arise with one version of cygwinb19.dll and one version of
| cygwin1.dll ?

Let's just say that version b19 is "very very very very old" and,
indeed, obsolete...
But anyway the new tools shouldn't have problems if a DLL *with a
different name* is found in the system.

BT:W notcie that my answer is not authoritative, only CGF and a few of
other can give those...

- --
Lapo 'Raist' Luchini
lapo@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAj9XClMACgkQaJiCLMjyUvvSogCdFK6jK+YHD+HXFkna4/BZmEns
DT0AoIwxXrbDKUXvOK6G8VA052UdYOyk
=qfmE
-----END PGP SIGNATURE-----



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

cygwinb19.dll

[jurgen.defurne]

Dear all,

We have a product Tornado from WindRiver, which uses cygwinb19.dll.

The Tornado compiler generates an access violation on the workstation
which also happens to run a more recent version of Cygwin. This access
violation takes place in the cygwinb19.dll.

I happen to know from previous discussions that one should not have
several versions of cygwin1.dll in his path. Does the same problem
arise with one version of cygwinb19.dll and one version of cygwin1.dll ?

Regards,

Jurgen

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwinb19.dll

[Michael Hirmke]

Hi Robert,

[...]
>#In this case of course the same directory would be the appropriate
>#place. But to keep all apps in one directory is another bad idea IMHO ;)
>
>When I talk about binaries, I'm meaning my programs, not the suite that
>comprises CYGWIN. Since,
>I'm not planning on turning out 100's of programs, only maybe half a dozen,
>surely that would be
>okay to plant them in the same directory?

Yes, of course :)
I recognized, that you did not mean the Cygnus CDK, but I thought, you
really intend to distribute a few large apps. In this case, it wouldn't
be a good idea to put them all in one single directory. But if you want
to give away only some small programs and you know, that on these
systems there is no Cygnus CDK installed, it is perfectly ok to put the
dll into the same directory as your programs.
IMHO of course :)

>
>Is there something I've missed, after all, you're the expert - not me ;-)

I'm not an expert, at most I'm an experienced user.

>
>
>By the way, thanks for your work on CYGWIN, e.g. the program ports faq. I
>often think that us users don't
>take enough time to thank developers and gurus like you for all their hard
>work ....

Great to hear that you like my report :)
Besides that it would also be great, if more people could contribute to
it. I often see packages somewhere, which I don't know and which are not
in this report. This report is only useful, if as many people as
possible make there contributions.

>
>Bye.
>
>Bob Cross.

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Cygwinb19.dll

[Paul Shirley]

In message < 01IYVQHEJGQQ00007Z@scottish-newcastle.co.uk >,
Robert.Cross@scottish-newcastle.co.uk writes
>(Side point, I remember reading somewhere that Win'95 has quite a low limit on 
>the number of files permitted
>in a directory. If this is true, then surely that's another good reason not to 
>stuff all DLL's in the one place, "x:\WINDOWS\SYSTEM" ?)

AFAIK it only affects root directories (which is of course why you don't
put files in drive roots) There are 2 problems, one is a fixed directory
limit (256 or 512?, not sure) and the LFN support chews multiple entries
for each object in the root.
I have one directory with 2,100 files in it at the moment, no obvious
problems.

-- 
Paul Shirley
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Cygwinb19.dll

[Leo Mauro]

On Wednesday, July 01, 1998 04:13 AM, Robert Cross wrote:

> Side point, I remember reading somewhere that Win'95 has quite a 
> low limit on the number of files permitted in a directory.

Not completely true. The root directories of FAT partitions have a
fixed size (established at format time), and cannot grow.  All other
directories can grow dynamically, and therefore have no other limit
than the one imposed by available free space.  I do not remember
out of the top of my head how FORMAT decides what the root
directory's size should be, but I do remember that a directory can
store 16 entries per 512-byte sector.

Anyway, the root directory's capacity is fairly generous.  I just
did a spot check of 5 FAT partitions in 3 different drives, and the
diagnostic tool reported capacities ranging from 512 to 800
entries in the various root directories.  But remember that long
file names take up two or more entries: one or more to store the
long file name (depending on how long it is), and another for the
abbreviated 8.3 DOS name.

The only case I remember of the root directory size limit actually
revealing itself was when a partition repair tool created hundreds
of files and directories in the root directory as it repaired a badly
damaged file system.  That tool eventually couldn't create any
more entries and stopped.  The partition was so badly damaged
anyway that I ended up reformatting it...

Leo Mauro
Principal Scientist
TeleSys Technologies, Inc.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Cygwinb19.dll

[Michael Hirmke]

Hi Robert,

[...]
>#So, you would put a copy of cygwin.dll to every directory you want to
>#have a cygwin32 binary in ? Bad idea IMHO.
>
>Agreed, that's why I wouldn't do it  =8-o
>
>If/when I start shipping code I'd prefer, to make it easier to audit, to keep
>all CYGWIN-produced binaries
>in one place. So, correct me if I'm wrong, that's the best place to put the
>.DLL?!

In this case of course the same directory would be the appropriate
place. But to keep all apps in one directory is another bad idea IMHO ;)

>
>(Side point, I remember reading somewhere that Win'95 has quite a low limit
>on the number of files permitted
>in a directory. If this is true, then surely that's another good reason not
>to stuff all DLL's in the one place, "x:\WINDOWS\SYSTEM" ?)

This limitation is true only for the root directory.

>
>Bob

BYe.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Cygwinb19.dll

[Robert.Cross]

>I think the former would be the best. I really loathe app's that insist on
>putting
>their junk in the WINDOWS tree - after all those directories are/should-be
>reserved
>for Microsoft's junk <g>

#So, you would put a copy of cygwin.dll to every directory you want to
#have a cygwin32 binary in ? Bad idea IMHO.

Agreed, that's why I wouldn't do it  =8-o

If/when I start shipping code I'd prefer, to make it easier to audit, to keep 
all CYGWIN-produced binaries
in one place. So, correct me if I'm wrong, that's the best place to put the 
.DLL?!

(Side point, I remember reading somewhere that Win'95 has quite a low limit on 
the number of files permitted
in a directory. If this is true, then surely that's another good reason not to 
stuff all DLL's in the one place, "x:\WINDOWS\SYSTEM" ?)

Bob

RE: Cygwinb19.dll

[Robert.Cross]

#  However, practically all Win32 programs require at least
# one of the Win32 API DLLs, directly or through some other library or DLL, so
# basically all Win32 programs are dynamically linked. To achieve something
# like a UNIX statically linked executable what you need to do is make sure
# you don't link any DLLs which don't come with the operating system.

That would be a little tricky....

# So, either you can rebuild newlib as a static library, or you can distribute
# a copy of cygwin's dll with your program (or you can use Mingw32, but that
# would be a shameless plug :-) ).

I think the Mingw32 route sounds best, (well it's easiest for me - so it's 
obviously
the best!).

Bob

Re: Cygwinb19.dll

[Michael Weiser]

Hi Edward,

You wrote:

>>if a person is running more than 1 Cygnus compiled application at a
>>time, you are saving on memory space and harddrive space to go with
>>dynamic linking.
>AFAIK, Windows loads a _separate copy_ of each DLL for every program
>that uses it.  That's one of the reasons it uses so much memory.
>
>(Please tell me I'm wrong... :-( )
AFAIK you are wrong. Doing so would turn the concept of dynamic
linking for saving memory into absolute nonsense. :)

bye

Michael
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Cygwinb19.dll

[Robert.Cross]

# That sounds like the perfect way of making non-DLL requiring EXEs w/
# Cygnus..  But, would statically linked EXEs be worth the extra size?  That's
# my main concern, especially since if a person is running more than 1 Cygnus
# compiled application at a time, you are saving on memory space and harddrive
# space to go with dynamic linking.

Agreed. What I was getting at was the situation where you want to deliver a 
"gnu-win32"
generated ''solution'' with the minimum of hassle. With the static link, you 
one have one
(veRY LARge) exe, rather than one exe and a DLL that has to go lord-knows-where 
- maybe
package creation, a la Solaris is the answer?

What do you think?

Bob Cross.