I want to hear…”Hello, again from general Windows H/W.”
Don’t want slimmer notebooks, non customizable H/W. non-retina MBP and polycarbonate MB had easiest upgradability of RAM and storage devices.
They got rid of those options from MBs and even from Mac minis. Instead of making adding or replacing internal storage in Mac mini, they removed memory slots, and kept it difficult to upgrade.
Due to the cylindrical Mac Pro, extension card manufacturers need to design additionally for Mac Pro and hire device driver engineers. It reduced chance for video card companies to prepare one designed for general Windows PC for Mac with a driver for Mac.
It also raised costs
Seriously, other than S/W developers who know the benefit of Cocoa, who will choose Mac over Windows when they have the same Photoshop, Adobe Premiere etc?
I like Apples aesthetic side of MacBook Pros, but do Dell’s XPS notebook look bad? No!
There can be less expensive but good looking computers with good qualities! Why do 🍎’s product decision makers overlook that fact?
It will be better if there is OS X for Windows box. (Anyway there is no difference in their H/W arch.)L
Or if Visual c++ also supports Obj-C, Cocoa and Av foundation etc!
Well, if you are a hardcore programmer, probably Interface Builder on Mac or the integrated resource editor for Visual Studio can be good enough. But there are certain times to define how things work in advance, or those tools are not easy for GUI designers to use.
Then… it’s time you need a GUI prototyping tool.
There have been many, but nowadays, these two commercial S/W programs appear on Google.
We can use trial versions to see how they work.
I have an old project for converting wrongly encoded Korean to properly encode to properly encoded one in mp3 files.
However due to file system corruption while in upgrading to OS X 10.11.6, I had to rebuild the project again. I found out that I had another project for the same purpose to use different ID3 library. I didn’t remember which project was correct one.
I finally identified the correct one, but had some issues. It was built previously without a problem, but it failed this time. It could be due to changes in Xcode. Yes. there is such change. I will talk about that after taking about difference of libiconv from OS X and Mac Port.
When tried to build, it complaint _iconv, _iconv_open, _iconv_close were missing.
I recalled that there was difference between libiconv from OS X and Mac Port, and there was a comment I wrote for that, but didn’t remember its detailed reasoning for that.
So, I googled and found the stack overflow question above, and it made me recall what problem it had completely.
So, this time I would like to record it here.
This is the result with libiconv from Mac Port.
JongAms-Mac-mini:lib jongampark$ nm -m libiconv.2.dylib | grep iconv
0000000000002db1 (__TEXT,__text) external _libiconv
0000000000002dd3 (__TEXT,__text) external _libiconv_close
000000000000158c (__TEXT,__text) external _libiconv_open
This is the result with libiconv from OS X.
JongAms-Mac-mini:lib jongampark$ nm -m /usr/lib/libiconv.dylib | grep iconv
000000000000301c (__TEXT,__text) external _iconv
000000000000336d (__TEXT,__text) external _iconv_canonicalize
000000000000303e (__TEXT,__text) external _iconv_close
0000000000001c41 (__TEXT,__text) external _iconv_open
So, the difference is that the ones from Mac Port have _lib is prefixed while the ones from OS X don’t.
Also, the included iconv.h file should match with the library file.
Finally I would like to talk about the changes of Xcode behavior.
With a version of 7.x.x, Apple changed that default libraries and header files could be searched without specifying them. Especially, if a library, for example, /usr/lib/libiconv.dylib is linked using the build phase, Xcode didn’t require the /usr/lib is added to the library search path. It was new behavior at that time.
However, they changed it again from some version of Xcode later than the version mentioned above. So, the library path should be set to include /usr/lib.
Without that, even though the /usr/lib/libiconv.dylib is linked by build phase setting (Link Binary with libraries ), Xcode couldn’t find that it’s in /usr/lib.
Apple doesn’t document this kind of changes, and it gives headache.
I wonder why Apple keeps changing from one behavior to the other behavior from time to time. If they keep changing to a newer behavior, it could be understandable, although I don’t like it. However, they are kind of going forward and backward.
This is small difference, but can affect big way.
Apple should document this kind thing and handle this seriously.
It’s explained here, but ‘how to use’ is buried in the long text without indentation etc.
- To type U+03B1, press the “Option” key.
- press 0, 3, B, 1 while still pressing the “Option” key.