 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / January 2006MAC_OS_X_VERSION_MAX_ALLOWED?
Just starting OS X development for the first time. I wrote Mac code in the 90's, but never had a chance for a OS X project till now (been on the Dark Side with VC++ the past few years) I was handed a project started by another programmer that had to bail, and am trying to get it to build. I have gone through the first few chapters of "Cocoa Programming For Mac OS X" by Hillegass to get the basic foundation. I try to build this inherited code, and get an error in my xx_prefix.pch saying MAC_OS_X_VERSION_MAX_ALLOWED must be >= MAC_OS_X_VERSION_MIN REQUIRED Doing a search on the project, I can't see where either is defined though. I _do_ find the check in foundation.h, which is imported in cocco.h, which is imported in xx_prefix.pch. Where do I find these constants? While we are at it, any other hints in general to getting someone else's code running on my machine? Any common gotcha's when moving between developer's machines that I should know about?  Signature- Burt Johnson MindStorm, Inc. http://www.mindstorm-inc.com/software.html > Just starting OS X development for the first time. I wrote Mac code in > the 90's, but never had a chance for a OS X project till now (been on [quoted text clipped - 19 lines] > code running on my machine? Any common gotcha's when moving between > developer's machines that I should know about? Create a New project of a similar type with the correct name, using XCode's New Project menu command, then, in the Finder, copy over your sources into the new project's folder, then, with XCode over, drag the sources onto the project window. That will at least set up your precompiled prefix and general build environment. The correct name, because you'd have to go to many arcane dialog boxes and config files to change it later. Command-clicking on MAC_OS_X_VERSION_MAX_ALLOWED or on MAC_OS_X_VERSION_MIN_REQUIRED shows that they are defined in /usr/include/AvailabilityMacros.h or: /Developer/SDKs/MacOSX10.4.0.sdk/usr/include/AvailabilityMacros.h if you are using one of the /Developer/SDKs to specify a specific software version. Biggest gotcha is non-system libraries that you forget to move, or add to your project, so that the code is actually linked in. Also, if you are using Cocoa, and you have ZeroLink turned on, your program will happily run with some missing libraries, with messages to non-existent objects just returning nil. > Create a New project of a similar type with the correct name, using > XCode's New Project menu command, then, in the Finder, copy over your [quoted text clipped - 21 lines] > happily run with some missing libraries, with messages to non-existent > objects just returning nil. Thanks! Leave it to you to have the answer, and to do so within a few minutes of my posting! :-) Glad to see you are still active in Mac stuff. I've been doing Windoze video editing software for the past couple years. This is my first chance to get back to Mac apps since Sonic. Signature- Burt Johnson MindStorm, Inc. http://www.mindstorm-inc.com/software.html > Glad to see you are still active in Mac stuff. I've been doing Windoze > video editing software for the past couple years. This is my first > chance to get back to Mac apps since Sonic. Thanks for the kind words. I'm happy that I could help you. David Phillip Oster David - thanks for your help. That definitely got me well past that initial startup problem. I now find that the prior code is using typedef BYTE and typedef DWORD and that the compiler is saying 'parse error before xxx' (xxx being the variable following those keywords) Does OC (what _is_ the accepted shorthand for Objective-C? Can't see typing that out every time...) not have those types? I presume they are called by a different name? And what is a good way to find stuff like that? The online help seems to be for XCode, not Objective-C. I entered 'data type' in the search, and found how to view them in the debugger, but not what types were defined in OC...? > David - thanks for your help. That definitely got me well past that > initial startup problem. [quoted text clipped - 18 lines] > and found how to view them in the debugger, but not what types were > defined in OC...? Well, I opened an Obj-C project, typed <Control>-N to get a new clean text file to type, typed "BYTE", selected it, and <Command>-<Double-Click>ed it. Ditto for "DWORD". Both came up blank. Compare with: SInt8 SInt64 which opened up MacTypes.h and selected the definition of those symbols. Is a BYTE signed or unsigned? Is a DWORD signed or unsigned? Is it 32 bits or 64 bits? If you are sure that no-one on your project will ever get confused, you add typedefs yourself to your XXXX_Prefix.pch file. Tips & Tricks: In addition to <Command>-<Double-Click> on an identifier which opens the place where it is declared. <Option>-<Double-Click> will open the manual page for the function, class, or macro, if there is one. <F5> brings up the pop-up menu of completions. For example, if you write: - (int) foo: (NSMutableArray*) ary { [ary a<F5> then you'd get a popup menu of the methods on NSMutableArray whose names start with "a". You can keep typing to refine the menu. I don't think there is any single page description of Cocoa. However, the pair of: http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_ classic/ http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/O bjc_classic/ cover most of the basics. Both are referenced from: http://developer.apple.com/documentation/Cocoa/ObjectiveCLanguage-date.ht ml which lists a few more, like Webkit, Core Data, Screen Savers, etc. Thanks for the help! I've printed this out and will review it tomorrow in more detail. The prior programmer is not available, and there is no Mac knowledge at all in this client company. I have just received the prior code tonight, so I haven't yet gotten far enough to know those details. With your prodding, I'll be sure to find out though. :-) fwiw, this is a program that will talk to a USB device, gather information, and then send it on to a web site. I see that the existing code includes 'HID Library' including a m/h with the product name. As such, I am assuming he either got the USB portion working, or was working on it when he left. In fact, I see all the parts of the code that I would expect will be needed -- UI stuff, network stuff with names like HttpClient, HttpLink, HttpUploadPacket, along with authorization, etc. Looks to me like the whole shebang may already be there. Clearly it is not working yet though (or he would have turned it in as done), so once I get it all compiled, I will have to find out what is missing or not working. > Well, I opened an Obj-C project, typed <Control>-N to get a new clean > text file to type, typed "BYTE", selected it, and [quoted text clipped - 45 lines] > > which lists a few more, like Webkit, Core Data, Screen Savers, etc. Signature- Burt Johnson MindStorm, Inc. http://www.mindstorm-inc.com/software.html > > David - thanks for your help. That definitely got me well past that > > initial startup problem. [quoted text clipped - 19 lines] > > Is a DWORD signed or unsigned? Is it 32 bits or 64 bits? I had to hit MSDN for it (ewwwww) but here's a summary: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/html/_m fc_data_types.asp BYTE An 8-bit integer that is not signed. DWORD A 32-bit unsigned integer ... > If you are sure that no-one on your project will ever get confused, you > add typedefs yourself to your XXXX_Prefix.pch file. Unless there is a good reason, and there rarely is, don't create yet another homebrew bunch of generic integer types for your project. Either use C's standard types (have always been good enough for me, anyway), the perfectly good sized types provided by Apple (or M$, if you swing that way) but don't roll your own. Think of the children. --T > ... > BYTE An 8-bit integer that is not signed. > DWORD A 32-bit unsigned integer ... [quoted text clipped - 7 lines] > anyway), the perfectly good sized types provided by Apple (or M$, if > you swing that way) but don't roll your own. Think of the children. If you need to sync up that code with a Windows version later, I'd suggest just typedef'ing them to UInt8 and UInt32 (which are the Mac equivalents, and are guaranteed to be). Neither char nor short nor long are really guaranteed to be any particular size in . In fact, short was 2 bytes on 68k Macs (at least usually, some compilers let you switch it to other sizes), and now is 4 bytes on PPC, and who knows what size it'll be on IA64 Macs once those hit the shelves... If you don't need to sync them up, I'd just suggest you go and do a search-and-replace to turn the Windows types into their Mac equivalents. Cheers, -- Uli > > BYTE An 8-bit integer that is not signed. > > DWORD A 32-bit unsigned integer ... [quoted text clipped - 11 lines] > suggest just typedef'ing them to UInt8 and UInt32 (which are the Mac > equivalents, and are guaranteed to be). ...and a guarantee is rarely needed beyond what *is* guaranteed by the C standard. When it is, use the sized types... > Neither char nor short nor long > are really guaranteed to be any particular size in . In fact, short was > 2 bytes on 68k Macs (at least usually, some compilers let you switch it > to other sizes), and now is 4 bytes on PPC, It's not 4 bytes on any PPC compiler I've used. > and who knows what size > it'll be on IA64 Macs once those hit the shelves... What about (64-bit) G5s? char, short and long did not change size for those either. > If you don't need to sync them up, I'd just suggest you go and do a > search-and-replace to turn the Windows types into their Mac equivalents. > > Cheers, > -- Uli > > BYTE An 8-bit integer that is not signed. > > DWORD A 32-bit unsigned integer ... [quoted text clipped - 11 lines] > suggest just typedef'ing them to UInt8 and UInt32 (which are the Mac > equivalents, and are guaranteed to be). Actually, I'd recommend looking into what stdint provides. Instead of the "Mac equivalents" it's nice to have actual standard types with known sizes. > Neither char nor short nor long > are really guaranteed to be any particular size in . In fact, short was > 2 bytes on 68k Macs (at least usually, some compilers let you switch it > to other sizes), and now is 4 bytes on PPC, and who knows what size > it'll be on IA64 Macs once those hit the shelves... I think you mean int. I've never seen a 4-byte short (even today on my G5) on a Mac. G Signature"Congurutulation!!!" - The subject line on some spam I received last night. I have no idea what it means, but it's such a cool "word" (by which I mean pronouncable sequence of letters) regardless. > I think you mean int. I've never seen a 4-byte short (even today on my > G5) on a Mac. You're right. Slip of the metaphorical tongue. -- Uli > Is a BYTE signed or unsigned? > > Is a DWORD signed or unsigned? Is it 32 bits or 64 bits? > > If you are sure that no-one on your project will ever get confused, you > add typedefs yourself to your XXXX_Prefix.pch file. hmmm... I opened up the XXXX_Prefix.pch and see this at the beginning: -------------------------- #ifdef __OBJC__ #import <Cocoa/Cocoa.h> typedef unsigned char BYTE; typedef unsigned long DWORD; typedef unsigned short WORD; typedef UInt64 UINT64; ---------------------------- Given that, why would the compiler have complained about BYTE and DWORD? When I did a 'build' tonight (not having changed the code at all), it did not complain about those, but rather about LPCSTR. 1) Why would there be a difference from one build to the next with no change in code? Does XCode need to exercise itself to find all the files?? 2) Looks like the code I have is just the PC version with the start of a port done. Things like LPCSTR are clearly VC++ data types, so I will now change my orientation from seeing if it works to seeing how far through the porting he got before he bailed. Signature- Burt Johnson MindStorm, Inc. http://www.mindstorm-inc.com/software.html > 1) Why would there be a difference from one build to the next with no > change in code? Does XCode need to exercise itself to find all the > files?? Xcode isn't as good at dependency tracking as some other systems. If you get puzzling behavior, you may need to do a "Clean All", deleting precompiled headers, to get behavior you expect. On particularly bad days, you'll need to manually delete /Library/Caches/com.apple.Xcode.501/SharedPrecompiledHeaders/ in addition. (Where 501 is your user id number). > 2) Looks like the code I have is just the PC version with the start of a > port done. Things like LPCSTR are clearly VC++ data types, so I will > now change my orientation from seeing if it works to seeing how far > through the porting he got before he bailed. Is LPCSTR one of those Windows things that is sometimes typedef char * const LPCSTR; and sometimes typedef Unichar16 * const LPCSTR; depending on some compile time setting? The OS X API is UTF-8, except when it is UCS-2, or sometimes, for backward compatiblity MacRoman Pascal strings. The whole mess is usually encapsulated as a CFStringRef, which is toll-free bridged to an NSString. If you can work in Cocoa, NSStrings are by far the best way to go. Be sure to read the chapter in the Hillegas book on localization, since you can't put non-ASCII in NSString literal constants in your objective-C code. Common MacRoman characters like ellispis and curly-quotes are not allowed. @"³You can¹t do thisŠ²" Instead you'll write things like this: NSString* description = NSLocalizedString( @"You don\\U2019t have permission to make changes to that file.", @"Failed to Save error panel message (format string)" ); and use the genstrings command-line tool to get that turned into a curly-single-quote in the Contents/Resources/English.lproj/Localized.strings file. Caution, NSLocalizedString() is not a compile-time operation, so if you use it at the global scope, you'll cause memory leaks and diagnostics will print on the console. Only call NSLocalizedString() from inside a function. There is a Unicode character palette that you can access if you go to "Input Menu" pane of the "International" panel of System Preferences, so you can get the number of the ellispis and curly-quote characters. > Caution, NSLocalizedString() is not a compile-time operation, so if you > use it at the global scope, you'll cause memory leaks and diagnostics > will print on the console. Only call NSLocalizedString() from inside a > function. Well, main() is a function, too, and you can get the error there, too. The point is you need to have an NSAutoreleasePool in place to use it. If you're in an action method in AppKit (or in a function or method called by it in the same thread -- which usually is where apps have their code), you get one for free, otherwise you'll get an error and have to create the pool yourself. Just nitpicking, -- Uli http://www.zathras.de >> Caution, NSLocalizedString() is not a compile-time operation, so if you >> use it at the global scope, you'll cause memory leaks and diagnostics >> will print on the console. Only call NSLocalizedString() from inside a >> function. > > Well, main() is a function, too, and you can get the error there, too. Actually, you'll get a completely different thing, and it's just a warning here. If you call it in main() without an autorelease pool, you'll get a warning that Cocoa has been forced to leak some objects. This is unpleasant and should be avoided, but it's not a big problem in the great scheme of things. If you call it as part of a global object initializer, then you'll either get a compiler error (for ObjC) or you'll get code that is highly likely to crash on startup in strange and fascinating ways (for ObjC++). This is because in C, global initializers must be constant expressions. In C++ they can be nonconstant, but the code generated executes very early, and this tends to be before the ObjC runtime and Cocoa are properly initialized. SignatureMichael Ash Rogue Amoeba Software > hmmm... I opened up the XXXX_Prefix.pch and see this at the beginning: > [quoted text clipped - 10 lines] > > Given that, why would the compiler have complained about BYTE and DWORD? Did you specify that file's name to be the precompiled header in your Xcode project file? > When I did a 'build' tonight (not having changed the code at all), it > did not complain about those, but rather about LPCSTR. See someone else's mention of dependency tracking iffyness. Note that I never had to delete the shared caches. Usually a "Clean" in Xcode is enough. > 2) Looks like the code I have is just the PC version with the start of a > port done. Things like LPCSTR are clearly VC++ data types, so I will > now change my orientation from seeing if it works to seeing how far > through the porting he got before he bailed. Have fun ;-) Cheers, -- Uli http://www.zathras.de > I now find that the prior code is using > [quoted text clipped - 6 lines] > and that the compiler is saying 'parse error before xxx' (xxx being the > variable following those keywords) Hi, AFAIR, BYTE and DWORD are Win32 types (or even Win16? It's been ages...). I'm not really surprised they aren't there. MacOS traditionally used either the built-in types (i.e. char and short), or its own which, by convention, used mixed-case, i.e. "Boolean". I don't recall any MacOS version having had all-upercase types (then again, I wasn't there before 6.x...). What is this old code you're porting? Windows? NeXT? Classic? Carbon? I could guess that NeXT may have had such types, but I wouldn't know for certain. > what _is_ the accepted shorthand for Objective-C? Usually I see it abbreviated "ObjC". Cheers, -- Uli Kusterer http://www.zathras.de >> AFAIR, BYTE and DWORD are Win32 types (or even Win16? It's been > ages...). I'm not really surprised they aren't there. MacOS [quoted text clipped - 6 lines] > could guess that NeXT may have had such types, but I wouldn't know for > certain. The original code was for the PC. Another Mac OS X programmer began writing a OS X version of the program in ObjC, then bailed. He is not available to talk to, has no documentation, and nobody at the company even knows the state of the code. I don't know at this point if it ever compiled, or if it was within a hair's breath of working fully. Adding the fact that I have never written OS X apps before, and this is teh real exploration time. (I wrote several Mac apps from 1985 till 1999, but then moved to Java and VC++ on the PC out of necessity) Signature- Burt Johnson MindStorm, Inc. http://www.mindstorm-inc.com/software.html |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.