RE: MIT shared memory extension

This is off-topic for the xfree mailing list, it's really a developer or general topic. Anyway -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 5:36 AM Robert Collins wrote: In short, I don't like the idea of making key_t 32 bits.

RE: MIT shared memory extension

This is off-topic for the xfree mailing list, it's really a developer or general topic. Anyway Should we move this to the cygwin list ? I'm not subscribed to the develop list. 1. Why do you use st_dev explicity. Isn't ftok() only for files ? From the ftok documentation: The ftok()

RE: MIT shared memory extension

Robert Collins wrote: In short, I don't like the idea of making key_t 32 bits. I have taken deeper into ftok and have some questions: 1. Why do you use st_dev explicity. Isn't ftok() only for files ? From the ftok documentation: The ftok() function returns a key based on path and id that is

RE: MIT shared memory extension

The definition of key_t in newlib is a 32bit int, for cygdaemon it needs to be 64 bit to store the inode and the index cleanly. Redefining that will break every cygipc linked application when they are rebuilt, until cygipc is rebuilt against the new source. However rebuilding cygipc will

RE: MIT shared memory extension

-Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 7:41 AM What about using a new type respective casts for cygdaemon. This would not break key_t compatibility and allows to migrate single application to cygdaemon, while others works

Re: MIT shared memory extension

Robert Collins wrote: -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 7:41 AM What about using a new type respective casts for cygdaemon. This would not break key_t compatibility and allows to migrate single application to cygdaemon,

RE: MIT shared memory extension

-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 10:20 AM the cygwin-daemon code was recently merged into CVS; the snapshots have the functionality but the daemon itself is not turned on by default. Just like ipcdaemon.exe,

RE: MIT shared memory extension

It works, we have done so for the kde-cygwin port Yeah, but it requires CygIPC, doesn't it? Yes, which is not distributed with cygwin because of license problems,.. the old story ... and I know, about what you like to talk - the new cygwin daemon, isn't it ? :-) BTW, has anybody tried

RE: MIT shared memory extension

-Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 04, 2002 8:55 PM To: Robert Collins; Charles Wilson Cc: [EMAIL PROTECTED] Subject: RE: MIT shared memory extension the cygwin-daemon code was recently merged into CVS; the snapshots

Re: MIT shared memory extension

/ arun [EMAIL PROTECTED] wrote: | hello, | | Does cygwin/xfree86 support MIT shared memory extension. I am trying to port | some code that uses these functions on linux. and I get a linker error. No it doesn't. It is possible though to compile xfree86 for cygwin with that enabled, but it

RE: MIT shared memory extension

It is possible though to compile xfree86 for cygwin with that enabled, but it haven't been tested, check the mailinglist. It works, we have done so for the kde-cygwin port Regards Ralf

Re: MIT shared memory extension

Ralf Habacker wrote: It is possible though to compile xfree86 for cygwin with that enabled, but it haven't been tested, check the mailinglist. It works, we have done so for the kde-cygwin port Yeah, but it requires CygIPC, doesn't it? BTW, has anybody tried to run kde-cygwin using the