December 2005 - Darwin-dev - lists.apple.com

Re: preprocessor definition identifying Mac OS X version
by Tommy Nordgren 12 Dec '05

12 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi all, Is there somewhere (presumably among the headers in /usr/include) a preprocessor definition I can use to know what version of Mac OS X some C source code is being compiled on ? "Home is not where you are born, but where your heart finds peace" - Tommy Nordgren, "The dying old crone" _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I suggest you try making diffs between files in /usr/include on a Tiger mac, and the equivalent files in the SDK:s for privious system releases Dec 12, 2005 kl. 9:26 PM skrev Aurelien Chanudet: Thanks, Aurelien _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tommy.nordgren% 40chello.se This email sent to tommy.nordgren(a)chello.se This email sent to site_archiver(a)lists.apple.com

1 0

preprocessor definition identifying Mac OS X version
by Aurelien Chanudet 12 Dec '05

12 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YqgcOSr2OQKG4UiHD2NwQ/1DmB1ZoffK/2Xz+alFixWc3KTamXDgmQjabkNuu/hmWjzn7q/chlcRhhFVwVulskqg+2U8AqLrpp3rrNmKEBhDuYOPk9NvNl8bAjvcE2zIy6W7EsH+UzLa8HqqEdRpW+iIT1lZyXW0+KhJzR1ZpN4= Hi all, Is there somewhere (presumably among the headers in /usr/include) a preprocessor definition I can use to know what version of Mac OS X some C source code is being compiled on ? Thanks, Aurelien _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Carbon shared libs in MachoPackage.app ?
by Ruslan Zasukhin 12 Dec '05

12 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcX/P1vpmlvsMGsyEdqJaQANkzDgag== Thread-topic: Carbon shared libs in MachoPackage.app ? User-agent: Microsoft-Entourage/11.2.0.050811 Hi All, I try now find way to put shared libs into MachoPackage.app which build REALbasic. IF I keep set of shard libs in the folder /Library/CFMSupport Then this application starts and work fine. so I can resume that macho app can use carbon shared libs. Good. Now I did hope that if I move that shared libs into .app/Contents/MacOS folder Then everything still will work. Because this follow Apples rules how it searches for shard libs: -- at first Application folder. But it not works. :-( I do not see reasons why. Anybody have idea how to force it to work ? -- Best regards, Ruslan Zasukhin VP Engineering and New Technology Paradigma Software, Inc Valentina - Joining Worlds of Information http://www.paradigmasoft.com [I feel the need: the need for speed] _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: CFMessagePort memory leak issue
by Philip Lukidis 11 Dec '05

11 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks for your reply, I'll see what leaks thinks about this. Philip Lukidis > -----Original Message----- > From: Stéphane Sudre [mailto:ssudre2@wanadoo.fr] > Sent: Friday, December 09, 2005 6:21 PM > To: Philip Lukidis > Cc: darwin-dev(a)lists.apple.com > Subject: Re: CFMessagePort memory leak issue > > > > vendredi 9 décembre 2005, à 11:38 PM, Philip Lukidis a écrit : > > > Hello, I have a strange issue when sending messages on > CFMessagePort. > > I > > will describe the general architecture first. I have a > daemon, which > > communicates with a framework (shared library) using UNIX > sockets. > > That > > seems to work fine. However, I need to provide 3rd party > applications > > with > > callbacks. The daemon sends a message to the shared > library, which in > > turn > > must notify the 3rd party application. I've chosen to take a > > application > > supplied callback and callback context, and call it via a > CFMessagePort > > callback. Both the remote port and local port are in the *same* > > process > > space, which is the one who mapped the shared library. > What I do is > > send > > when I receive a daemon message is call > CFMessagePortSendRequest, which > > invokes the remote port callback, which then directly calls > the 3rd > > party > > supplied callback function (and passes its context). Thus the 3rd > > party > > never has to deal with CFData references, or gets its hands on the > > ports. > > > > However, I'm seeing a memory leak over a long time. When I simply > > invoke > > the 3rd party callback without going through > CFMessagePortSendRequest, > > the > > private memory of the client process stays pretty constant. > However, > > when I > > use the CFMessagePortSendRequest, the private memory > balloons in size > > over > > several hours. Note that my reply mode for the > CFMessagePort is NULL, > > and > > my timeouts are zero (see code below). Also the remote > port callback > > returns NULL. I'll include the relevant code below. Note that if I > > allocate/free on the CFData for the message, but simply > invoke the 3rd > > party > > supplied callback without calling CFMessagePortSendRequest, > I have NO > > leak. > > So my management of the input data would appear to be correct, and > > somehow > > my calls to CFMessagePortSendRequest precipitate the leak. > Can anyone > > see a > > memory leak here? > > > > // REMOTE PORT CALLBACK- note that it returns NULL > > CFDataRef MessagePortNotificationCallbackFn( > > CFMessagePortRef local, > > SInt32 msgid, > > CFDataRef data, > > void *info > > ) > > { > > PORT_PACKET_FORMAT packet; > > CommonContext* pContext = (CommonContext*)info; > > > > memset(&packet,0,sizeof(PORT_PACKET_FORMAT)); > > CFDataGetBytes(data, CFRangeMake(0, > sizeof(PORT_PACKET_FORMAT)), > > (UInt8*)&packet); > > > > // call user registered callback > > if(pContext->NotificationCallback) > > { > > > > pContext->NotificationCallback(&packet,pContext- > > >NotificationCallbackContext > > ); > > } > > > > // don't return anything, we are in NULL reply mode > > return NULL; > > } > > > > // CODE WHICH CALLS THE REMOTE PORT: > > if(packetToSend) > > { > > memcpy(&localData,packetToSend,sizeof(PORT_PACKET_FORMAT)); > > sendData = CFDataCreate(kCFAllocatorDefault, > > (UInt8*)&localData, > > sizeof(PORT_PACKET_FORMAT)); > > > > if(!sendData) > > { > > break; > > } > > > > rc = CFMessagePortSendRequest(RemoteTargetPort, > > 0, > > sendData, > > sendTimeout, > // ALWAYS 0 > > 0, > > NULL, // > reply mode NULL, > > we don't wait for a reply.. > > NULL // we know > the remote > > port returns NULL, we don't care for this > > ); > > > > // we always release no matter what the return > > if(sendData) > > { > > CFRelease(sendData); > > sendData = NULL; > > } > > } > > What is leaks(1) saying? This may help you get an idea about > what kind > of object is leaked. > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: CFMessagePort memory leak issue
by Philip Lukidis 11 Dec '05

11 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks for your answer. The third party installed callback is empty for now, as I'm writing a test client. But if it did call back into the workloop somehow, wouldn't the stack eventually bust? Would the stack be automatically extended after a generated exception, or would the program crash or get corrupted? In any case, as the 3rd party callback does absolutely nothing, and returns nothing (it is void), I can't see this being the issue. However, this is something I definitely have to consider, so thanks for pointing it out. I guess I can have a worker pool to take care of this. Perhaps this is the preferred approach in any case. But say the stack was growing larger and larger, is there a diagnostic utility to verify this? Yes, you're quite right about extracting the packet, I'll put that in. Is there any tool for diagnosing CF type leaks? thanks, Philip Lukidis > -----Original Message----- > From: Kevin Van Vechten [mailto:kevin@opendarwin.org] > Sent: Friday, December 09, 2005 9:23 PM > To: Philip Lukidis > Cc: darwin-dev(a)lists.apple.com > Subject: Re: CFMessagePort memory leak issue > > > Is the "3rd party" callback entering into the run loop again? > If so, > you're probably recursing and the stack keeps getting deeper... > > Also, you should ensure that the data parameter to > MessagePortNotificationCallbackFn is at least sizeof > (PORT_PACKET_FORMAT) bytes long before calling CFDataGetBytes, > otherwise you may encounter unexpected results. > > - Kevin > > On Dec 9, 2005, at 2:38 PM, Philip Lukidis wrote: > > > Hello, I have a strange issue when sending messages on > > CFMessagePort. I > > will describe the general architecture first. I have a > daemon, which > > communicates with a framework (shared library) using UNIX > sockets. > > That > > seems to work fine. However, I need to provide 3rd party > > applications with > > callbacks. The daemon sends a message to the shared > library, which > > in turn > > must notify the 3rd party application. I've chosen to take a > > application > > supplied callback and callback context, and call it via a > > CFMessagePort > > callback. Both the remote port and local port are in the *same* > > process > > space, which is the one who mapped the shared library. What I do > > is send > > when I receive a daemon message is call CFMessagePortSendRequest, > > which > > invokes the remote port callback, which then directly calls > the 3rd > > party > > supplied callback function (and passes its context). Thus the 3rd > > party > > never has to deal with CFData references, or gets its hands on the > > ports. > > > > However, I'm seeing a memory leak over a long time. When I simply > > invoke > > the 3rd party callback without going through > > CFMessagePortSendRequest, the > > private memory of the client process stays pretty constant. > > However, when I > > use the CFMessagePortSendRequest, the private memory balloons in > > size over > > several hours. Note that my reply mode for the CFMessagePort is > > NULL, and > > my timeouts are zero (see code below). Also the remote > port callback > > returns NULL. I'll include the relevant code below. Note that if I > > allocate/free on the CFData for the message, but simply invoke the > > 3rd party > > supplied callback without calling CFMessagePortSendRequest, I have > > NO leak. > > So my management of the input data would appear to be correct, and > > somehow > > my calls to CFMessagePortSendRequest precipitate the leak. Can > > anyone see a > > memory leak here? > > > > // REMOTE PORT CALLBACK- note that it returns NULL > > CFDataRef MessagePortNotificationCallbackFn( > > CFMessagePortRef local, > > SInt32 msgid, > > CFDataRef data, > > void *info > > ) > > { > > PORT_PACKET_FORMAT packet; > > CommonContext* pContext = (CommonContext*)info; > > > > memset(&packet,0,sizeof(PORT_PACKET_FORMAT)); > > CFDataGetBytes(data, CFRangeMake(0, > sizeof(PORT_PACKET_FORMAT)), > > (UInt8*)&packet); > > > > // call user registered callback > > if(pContext->NotificationCallback) > > { > > > > pContext->NotificationCallback(&packet,pContext- > > >NotificationCallbackContext > > ); > > } > > > > // don't return anything, we are in NULL reply mode > > return NULL; > > } > > > > // CODE WHICH CALLS THE REMOTE PORT: > > if(packetToSend) > > { > > memcpy(&localData,packetToSend,sizeof(PORT_PACKET_FORMAT)); > > sendData = CFDataCreate(kCFAllocatorDefault, > > (UInt8*)&localData, > > sizeof(PORT_PACKET_FORMAT)); > > > > if(!sendData) > > { > > break; > > } > > > > rc = CFMessagePortSendRequest(RemoteTargetPort, > > 0, > > sendData, > > sendTimeout, > // ALWAYS 0 > > 0, > > NULL, // > reply mode NULL, > > we don't wait for a reply.. > > NULL // we know > the remote > > port returns NULL, we don't care for this > > ); > > > > // we always release no matter what the return > > if(sendData) > > { > > CFRelease(sendData); > > sendData = NULL; > > } > > } > > > > thanks for any insights, > > > > Philip Lukidis > > _______________________________________________ > > Do not post admin requests to the list. They will be ignored. > > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/darwin-dev/kevin% > > 40opendarwin.org > > > > This email sent to kevin(a)opendarwin.org > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: CFMessagePort memory leak issue
by Kevin Van Vechten 10 Dec '05

10 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com - Kevin On Dec 9, 2005, at 2:38 PM, Philip Lukidis wrote: // CODE WHICH CALLS THE REMOTE PORT: if(packetToSend) { memcpy(&localData,packetToSend,sizeof(PORT_PACKET_FORMAT)); sendData = CFDataCreate(kCFAllocatorDefault, (UInt8*)&localData, sizeof(PORT_PACKET_FORMAT)); if(!sendData) { break; } rc = CFMessagePortSendRequest(RemoteTargetPort, 0, sendData, sendTimeout, // ALWAYS 0 0, NULL, // reply mode NULL, we don't wait for a reply.. NULL // we know the remote port returns NULL, we don't care for this ); // we always release no matter what the return if(sendData) { CFRelease(sendData); sendData = NULL; } } thanks for any insights, _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Is the "3rd party" callback entering into the run loop again? If so, you're probably recursing and the stack keeps getting deeper... Also, you should ensure that the data parameter to MessagePortNotificationCallbackFn is at least sizeof (PORT_PACKET_FORMAT) bytes long before calling CFDataGetBytes, otherwise you may encounter unexpected results. Hello, I have a strange issue when sending messages on CFMessagePort. I will describe the general architecture first. I have a daemon, which communicates with a framework (shared library) using UNIX sockets. That seems to work fine. However, I need to provide 3rd party applications with callbacks. The daemon sends a message to the shared library, which in turn must notify the 3rd party application. I've chosen to take a application supplied callback and callback context, and call it via a CFMessagePort callback. Both the remote port and local port are in the *same* process space, which is the one who mapped the shared library. What I do is send when I receive a daemon message is call CFMessagePortSendRequest, which invokes the remote port callback, which then directly calls the 3rd party supplied callback function (and passes its context). Thus the 3rd party never has to deal with CFData references, or gets its hands on the ports. However, I'm seeing a memory leak over a long time. When I simply invoke the 3rd party callback without going through CFMessagePortSendRequest, the private memory of the client process stays pretty constant. However, when I use the CFMessagePortSendRequest, the private memory balloons in size over several hours. Note that my reply mode for the CFMessagePort is NULL, and my timeouts are zero (see code below). Also the remote port callback returns NULL. I'll include the relevant code below. Note that if I allocate/free on the CFData for the message, but simply invoke the 3rd party supplied callback without calling CFMessagePortSendRequest, I have NO leak. So my management of the input data would appear to be correct, and somehow my calls to CFMessagePortSendRequest precipitate the leak. Can anyone see a memory leak here? // REMOTE PORT CALLBACK- note that it returns NULL CFDataRef MessagePortNotificationCallbackFn( CFMessagePortRef local, SInt32 msgid, CFDataRef data, void *info ) { PORT_PACKET_FORMAT packet; CommonContext* pContext = (CommonContext*)info; memset(&packet,0,sizeof(PORT_PACKET_FORMAT)); CFDataGetBytes(data, CFRangeMake(0, sizeof(PORT_PACKET_FORMAT)), (UInt8*)&packet); // call user registered callback if(pContext->NotificationCallback) { pContext->NotificationCallback(&packet,pContext- >NotificationCallbackContext ); } // don't return anything, we are in NULL reply mode return NULL; } Philip Lukidis _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/kevin% 40opendarwin.org This email sent to kevin(a)opendarwin.org This email sent to site_archiver(a)lists.apple.com

1 0

Re: CFMessagePort memory leak issue
by Stéphane Sudre 09 Dec '05

09 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com vendredi 9 décembre 2005, à 11:38 PM, Philip Lukidis a écrit : // CODE WHICH CALLS THE REMOTE PORT: if(packetToSend) { memcpy(&localData,packetToSend,sizeof(PORT_PACKET_FORMAT)); sendData = CFDataCreate(kCFAllocatorDefault, (UInt8*)&localData, sizeof(PORT_PACKET_FORMAT)); if(!sendData) { break; } rc = CFMessagePortSendRequest(RemoteTargetPort, 0, sendData, sendTimeout, // ALWAYS 0 0, NULL, // reply mode NULL, we don't wait for a reply.. NULL // we know the remote port returns NULL, we don't care for this ); // we always release no matter what the return if(sendData) { CFRelease(sendData); sendData = NULL; } } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Hello, I have a strange issue when sending messages on CFMessagePort. I will describe the general architecture first. I have a daemon, which communicates with a framework (shared library) using UNIX sockets. That seems to work fine. However, I need to provide 3rd party applications with callbacks. The daemon sends a message to the shared library, which in turn must notify the 3rd party application. I've chosen to take a application supplied callback and callback context, and call it via a CFMessagePort callback. Both the remote port and local port are in the *same* process space, which is the one who mapped the shared library. What I do is send when I receive a daemon message is call CFMessagePortSendRequest, which invokes the remote port callback, which then directly calls the 3rd party supplied callback function (and passes its context). Thus the 3rd party never has to deal with CFData references, or gets its hands on the ports. However, I'm seeing a memory leak over a long time. When I simply invoke the 3rd party callback without going through CFMessagePortSendRequest, the private memory of the client process stays pretty constant. However, when I use the CFMessagePortSendRequest, the private memory balloons in size over several hours. Note that my reply mode for the CFMessagePort is NULL, and my timeouts are zero (see code below). Also the remote port callback returns NULL. I'll include the relevant code below. Note that if I allocate/free on the CFData for the message, but simply invoke the 3rd party supplied callback without calling CFMessagePortSendRequest, I have NO leak. So my management of the input data would appear to be correct, and somehow my calls to CFMessagePortSendRequest precipitate the leak. Can anyone see a memory leak here? // REMOTE PORT CALLBACK- note that it returns NULL CFDataRef MessagePortNotificationCallbackFn( CFMessagePortRef local, SInt32 msgid, CFDataRef data, void *info ) { PORT_PACKET_FORMAT packet; CommonContext* pContext = (CommonContext*)info; memset(&packet,0,sizeof(PORT_PACKET_FORMAT)); CFDataGetBytes(data, CFRangeMake(0, sizeof(PORT_PACKET_FORMAT)), (UInt8*)&packet); // call user registered callback if(pContext->NotificationCallback) { pContext->NotificationCallback(&packet,pContext- >NotificationCallbackContext ); } // don't return anything, we are in NULL reply mode return NULL; } What is leaks(1) saying? This may help you get an idea about what kind of object is leaked. This email sent to site_archiver(a)lists.apple.com

1 0

CFMessagePort memory leak issue
by Philip Lukidis 09 Dec '05

09 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hello, I have a strange issue when sending messages on CFMessagePort. I will describe the general architecture first. I have a daemon, which communicates with a framework (shared library) using UNIX sockets. That seems to work fine. However, I need to provide 3rd party applications with callbacks. The daemon sends a message to the shared library, which in turn must notify the 3rd party application. I've chosen to take a application supplied callback and callback context, and call it via a CFMessagePort callback. Both the remote port and local port are in the *same* process space, which is the one who mapped the shared library. What I do is send when I receive a daemon message is call CFMessagePortSendRequest, which invokes the remote port callback, which then directly calls the 3rd party supplied callback function (and passes its context). Thus the 3rd party never has to deal with CFData references, or gets its hands on the ports. However, I'm seeing a memory leak over a long time. When I simply invoke the 3rd party callback without going through CFMessagePortSendRequest, the private memory of the client process stays pretty constant. However, when I use the CFMessagePortSendRequest, the private memory balloons in size over several hours. Note that my reply mode for the CFMessagePort is NULL, and my timeouts are zero (see code below). Also the remote port callback returns NULL. I'll include the relevant code below. Note that if I allocate/free on the CFData for the message, but simply invoke the 3rd party supplied callback without calling CFMessagePortSendRequest, I have NO leak. So my management of the input data would appear to be correct, and somehow my calls to CFMessagePortSendRequest precipitate the leak. Can anyone see a memory leak here? // REMOTE PORT CALLBACK- note that it returns NULL CFDataRef MessagePortNotificationCallbackFn( CFMessagePortRef local, SInt32 msgid, CFDataRef data, void *info ) { PORT_PACKET_FORMAT packet; CommonContext* pContext = (CommonContext*)info; memset(&packet,0,sizeof(PORT_PACKET_FORMAT)); CFDataGetBytes(data, CFRangeMake(0, sizeof(PORT_PACKET_FORMAT)), (UInt8*)&packet); // call user registered callback if(pContext->NotificationCallback) { pContext->NotificationCallback(&packet,pContext->NotificationCallbackContext ); } // don't return anything, we are in NULL reply mode return NULL; } // CODE WHICH CALLS THE REMOTE PORT: if(packetToSend) { memcpy(&localData,packetToSend,sizeof(PORT_PACKET_FORMAT)); sendData = CFDataCreate(kCFAllocatorDefault, (UInt8*)&localData, sizeof(PORT_PACKET_FORMAT)); if(!sendData) { break; } rc = CFMessagePortSendRequest(RemoteTargetPort, 0, sendData, sendTimeout, // ALWAYS 0 0, NULL, // reply mode NULL, we don't wait for a reply.. NULL // we know the remote port returns NULL, we don't care for this ); // we always release no matter what the return if(sendData) { CFRelease(sendData); sendData = NULL; } } thanks for any insights, Philip Lukidis _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is AppleMacRISC4PE supposed to build at all ?
by Nigel Kersten 09 Dec '05

09 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Ok, that was my understanding, though I wondered if those bits were available somewhere else. The funny thing is almost all of these definitions seem to be very easily reconstructed by disassembling the binary AppleMacRISC4PE, I really don't understand Apple's point in hiding half of it like that .. This statement is so very wrong. -- Nigel Kersten [Senior Technical Officer] College of Fine Arts, University of NSW, Australia. CRICOS Provider Code: 00098G _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Benjamin Herrenschmidt wrote: I tried getting this to build to get 10.3 to run on the G5 iMacs when they were first released and spent a while on it with varying degrees of success. Dale Walsh wrote: Finlay Dobbie wrote: Last I heard, these are not available and are not likely to be made available. If you can build the project using darwinbuild then you can build the project alone. but you can't... that's the entire problem. The headers are not available. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Serial UPS Device
by Ethan Bold 09 Dec '05

09 Dec '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Chris- I'm happy to help out more with API's and ambiguities. Let me know. -ethan On Dec 8, 2005, at 11:40 AM, Chris McKinnon wrote: Hi, I've been looking into the Power Management APIs on OS X. I'm working on UPS monitoring software for a serial UPS and I would like to make the PM aware of the UPS. Most details I've seen about this relate to USB HID devices. I did notice on Apple's site a IOUPSPlugIn.h header. It looks like it can be used to create a plugin for ioupsd so it can communicate with the UPS. Am I on the right track? And, if so, does anyone know where I can get additional details on implementing a plugin? The header doesn't give a lot of detail. Thanks, Chris McKinnon _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/ebold%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… You're on the right track. You can create your own serial UPS plugin for ioupsd, and I'll point you at the right headers and the open source code that you'll need to interface with, but we don't have all the documentation for these API's that we'd like. A UPS plugin is a CFPlugin with a few defined entry points for reading capabilities, sending commands, etc. If you haven't yet, please check out the existing USB HID UPS plugin that's part of the IOHIDFamily Darwin project. http://www.opensource.apple.com/darwinsource/10.4.3/IOHIDFamily-172.8/ IOHIDLib/IOHIDUPSClass.cpp http://www.opensource.apple.com/darwinsource/10.4.3/IOHIDFamily-172.8/ IOHIDLib/IOHIDUPSClass.h This HID UPS Plugin fits into the ioupsd plugin, as any serial or network UPS plugin would. One importante difference is that OS X cannot automatically detect the presence of your serial UPS, so you'll need some software entity (a daemon, or a process launched by launchd) to ping ioupsd and tell it to load your plugin. This email sent to ebold(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0