January 2004 - Darwin-kernel

Re: Using struct proc
by Justin Walker 10 Jan '04

10 Jan '04

On Saturday, January 10, 2004, at 10:21 AM, Matt Jaffa wrote: Hi, Using the Proc structure, is there a way to get the information of the app's name, including the directory it is in? Like /Applications/TextEdit.app/contents/MacOS/TextEdit ? No. The proc structure contains a (possibly shortened) command name, but not the directory path. It also contains a pointer to the vnode for the executable. You could use that to work backwards to get "a" path to the executable. There really is no way to know what path was used (because of links, symbolic or hard). What are you trying to do? Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Some people have a mental | horizon of radius zero, and | call it their point of view. | -- David Hilbert *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Using struct proc
by Matt Jaffa 10 Jan '04

10 Jan '04

Hi, Using the Proc structure, is there a way to get the information of the app's name, including the directory it is in? Like /Applications/TextEdit.app/contents/MacOS/TextEdit ? Thanks Matt _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: OSUnserializeXML error
by Garth Cummings 09 Jan '04

09 Jan '04

Hi Eric, On Jan 8, 2004, at 3:07 PM, Eric Long wrote: Thanks for responding to my post. What happens if you manually change the type of that value from <real> to <integer>? I suspect the OSObject parser doesn't know anything about reals. I believe that's the problem. The call works if I make that change. Seems like the parser should handle it though. It seems inconsistent for the OS to support value types in one place and then not in another. The key is that floating point is discouraged in the kernel. Plus, the parser was intended to be used with OSObject serialization and not as a generic XML parser. Please feel free to file an enhancement request at <http://developer.apple.com/bugreporter> though. The app is using the standard OS functions to parse its plist file. We're not even enter the key/value pair. It's some underlying activity of Cocoa that is adding it to our file. Is there a specification for what values OSUnserializeXML() can and can't handle anywhere? No, other than the source. But I'd expect that anything that can be serialized via OSObject::serialize() and its subclasses would be unserializable. Thanks again, Eric You betcha, --gc _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

OSUnserializeXML error
by Eric Long 08 Jan '04

08 Jan '04

Hi, I have a kext that is passed XML data from userland. In the kext, I call OSUnserializeXML() to recreate the OSObject I need to process the data. This has all worked fine for awhile now, but in Panther a problem has crept up. The userland application is passing its entire plist dictionary to the kext. Most of the settings are relevant to the kext, but some are only relevant to the app. The app is a Cocoa app. We've found that if a user conducts certain actions within the application Cocoa adds this key/value pair to the app plist file: <key>NSNavBrowserPreferedColumnContentWidth</key> <real>186</real> When this key/value pair is present within the data our call to OSUnserializeXML() fails. All I have to go on is this information, which led me to the above key/value pair: Jan 8 09:27:17 localhost kernel: OSUnserializeXML: parse error near line 349 If I manually delete the pair from the app plist file, everything works correctly again. This seems like a bug in the OS, but maybe there's something I don't know about this. Has anyone else encountered this kind of problem with OSUnserializeXML()? Thanks, Eric Long ___________________________________________________________________________ Macintosh Software Engineer Aladdin Systems, Inc. http://www.aladdinsys.com 245 Westridge Drive, Watsonville, CA 95076 (831) 761-6200 x628 N 360 54.768 W 1210 46.990 _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: problem with connection
by Justin Walker 08 Jan '04

08 Jan '04

Please don't cross-post. On Wednesday, January 7, 2004, at 10:50 PM, nandkumar l mane wrote: How to accept connection from client in kernel mode using socket programming? The kernel implementation of the socket calls is contained in the files xnu/bsd/kern/{kern_socket.c,kern_socket2.c} If you are going to use these calls, you should be familiar with the implementation, since the requirements are much different than the corresponding user-mode socket calls. Generally, a socket API like 'foo(...)' is called 'sofoo()' in the kernel. The argument list is significantly different, however. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Udp multicast src address bug
by Justin Walker 08 Jan '04

08 Jan '04

On Wednesday, January 7, 2004, at 01:12 PM, Mark Koch wrote: Dear group, maybe I have found a bug in the udp stack of the darwin kernel. I found nothing via google or in the archives so I decided to post. Description: If a multicast address ist binded and connected the source address of sent packages is the multicast group address. I think there shall be the local interface address instead. This is a long-standing bug in the BSD stacks (Stevens discusses it in one of his books). RFC-1122 (Host Requirements) says that a multicast address not be used as the source address in any transmitted packet. The problem, I think, comes from the way the sockets API works. Stevens suggests that, to avoid this, you should use two UDP sockets, one for sending and one for receiving. You could file a bug on this (http://bugreporter.apple.com) but given it's long-standing nature, it may not be fixed. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Udp multicast src address bug
by Mark Koch 07 Jan '04

07 Jan '04

First I got the chance to check FBSD also, same behavior like Darwin. Stevens: Network Programming - Networking APIs S. 508 f RFC1122 (Branden, 1989): allowed addresses This behavior is documented and ok, but not intuitive (at least not for me :-( ). So this seems to me no longer as a bug now, but as inconvenient. I think I have to deal with this. Thanks for the help and fast replies, anyhow further comments would be nice :-). Mark _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Udp multicast src address bug
by Mark Koch 07 Jan '04

07 Jan '04

Dear group, maybe I have found a bug in the udp stack of the darwin kernel. I found nothing via google or in the archives so I decided to post. Description: If a multicast address ist binded and connected the source address of sent packages is the multicast group address. I think there shall be the local interface address instead. Verification: I verified the behavior on my computer running: Mark-Kochs-Computer:~ mkoch$ uname -v Darwin Kernel Version 7.2.0: Thu Dec 11 16:20:23 PST 2003; root:xnu/xnu-517.3.7.obj~1/RELEASE_PPC Mark-Kochs-Computer:~ mkoch$ aka MacOSX 10.3.2 (Panther). With developer tools as recent as possible, see: ++ (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for powerpc-apple-darwin7.0 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For the result see: Usage of sample code. I compared this to a system running Debian Gnu Linux/i386 (woody) where the expected behavior is present. You may be willing to verify this yourself, so I attached sample code in a zip-file called checkudp. Usage of sample code: In a terminal "cd" to the dir extracted from the zip file. Then build with "make". Now type something like: "./checkudp 192.168.1.2". This shall look like: Mark-Kochs-Computer:~/Desktop mkoch$ cd checkudp/ Mark-Kochs-Computer:~/Desktop/checkudp mkoch$ make g++ -g -Wall -c -o main.o main.cc g++ -g -Wall -c -o udp.o udp.cc g++ -g -Wall -c -o address.o address.cc g++ -g -Wall -c -o error.o error.cc g++ -g -Wall -c -o connection.o connection.cc g++ -o checkudp main.o udp.o address.o error.o connection.o Mark-Kochs-Computer:~/Desktop/checkudp mkoch$ ./checkudp 192.168.1.2 The src address is: 239.255.1.1 but shall be: 192.168.1.2. Mark-Kochs-Computer:~/Desktop/checkudp mkoch$ Any comments appreciated and thanks for your attention, Mark [demime 0.98b removed an attachment of type application/zip which had a name of checkudp.zip] _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: ClassicEnvironment
by Quinn 07 Jan '04

07 Jan '04

At 20:25 -0700 6/1/04, Matt Jaffa wrote: Is it possible to find out all the running apps in classic environment. You can do this via the Carbon Process Manager (or, indeed, the Process Manager within Classic itself). The can iterate the process list, which includes processes running within Classic, using the call GetNextProcess. For this to work you have to be running within the bootstrap port context of the GUI user. That is, GetNextProcess will not return meaningful results if you call it from a daemon. You have to call it from a process that's launched within the user's bootstrap port context. See the "Bootstrap Contexts" chapter of "Inside Mac OS X: Kernel Programming" for more details. <http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgrammin…> Working out which Carbon process is responsible for which DLIL-level I/O is going to be tricky. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: ClassicEnvironment
by Justin Walker 07 Jan '04

07 Jan '04

On Tuesday, January 6, 2004, at 07:25 PM, Matt Jaffa wrote: Hi all, Is it possible to find out all the running apps in classic environment. Not directly from the Mac OS X side. I believe that the Mac OS X Finder communicates somehow with the Classic 'environment' so that individual Classic apps show up in the dock, but I don't think that set of APIs is public. There's definitely no way to get that information directly from the kernel. My KEXT is a dlil interface filter, it gets the current proc, however there is only on pid for a classic app, the TruBlueEnvironment. By using that is it possible to find out all the running apps under that, since a classic app running in TruBlueEnvironment does not have its own unix pid. Correct. 'Classic' is a more-or-less complete Mac OS 9 environment in a process. That was the simplest way to get the kind of fidelity needed. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | "Weaseling out of things is what | separates us from the animals. | Well, except the weasel." | - Homer J Simpson *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0