Re: Porting from Windows to MAC related issues...
Re: Porting from Windows to MAC related issues...
- Subject: Re: Porting from Windows to MAC related issues...
- From: David Gatwood <email@hidden>
- Date: Fri, 4 Mar 2011 12:27:57 -0800
On Mar 4, 2011, sheetal phirke wrote:
> We want to port a product from Windows to MAC. We are new to mac, we have
> Windows experience.
> After doing certain analysis we have list of queries such as : * Character set
> support for UNICODE (like we use wchar in windows)
> * How can we avoid string related buffer overflows? ( similar to string safe
> functions in windows)
> * Is there any support for Exporting functions using ordinals?
> * Are there any porting related issues for 64 bit platform?
> * We have various file related operations, so if we decide to use POSIX
> functions which provides only interface for character (char *), there will be a
> need for conversion of wide char path to char each time. Is there any feasible
> solution for it?
> * Can all these issues be resolved if we go with Objective C (Cocoa framework)
Are we talking about a driver here? If not, you're on the wrong mailing list.
Assuming you mean an application:
1. For wide characters, although Mac OS X does provide wchar, most folks working with them on the Mac side tend to prefer the CFString/NSString functionality. YMMV.
2. Depends on what API you're using. With CFString and NSString, you get this for free. For C strings, we generally recommend the "l" variants, e.g. strlcat, strlcpy, etc., but Mac OS X also provides the 'n' variants.
3. Not to my knowledge. AFAIK, a function must be exported by name.
4. Yes, there are lots of 64-bit-specific things to pay attention to; not all APIs are available in a 64-bit environment. See 64-bit Transition Guide on developer.apple.com and the docs that it links to for more information.
5. Mac OS X's POSIX functions take UTF-8 strings. I'm not aware of any way around having to convert to UTF-8.
6. If you use NSString/CFString instead of wchar, then probably, yes.
In all of the above answers, I'm assuming that you're talking about an application here and not kernel code. If you really are talking about a kernel extension, then the answers are:
1. No. The kernel does not provide any wide character support internally, period. As far as the kernel is concerned, filenames are a bag of bytes.
2. Same as #2 in the previous list.
3. Same as #3 in the previous list.
4. same as #4 in the previous list.
5. Again, no support for wchar in the kernel, so you'll have to do that conversion before you pass it up to the kernel from your application. Also, POSIX file operations are not supported in the kernel, so if that's what you're trying to do, you're in for a significant re-architecting of your code.
6. Cocoa and friends are not supported in the kernel.
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden