I'm writing code specific for MountainLion so I want to try to avoid to use deprecated APIs.
I use FSFileOperationCreate to receive information about copy progress (kFSOperationBytesCompleteKey, kFSOperationThroughputKey, kFSOperationTotalBytesKey) but documentation says
Creates an object that represents an asynchronous file operation.
(Deprecated in OS X v10.8. At the Foundation layer, use
copyItemAtURL:toURL:error: instead. At the POSIX/BSD layer, use
copyfile(3) OS X Developer Tools Manual Page instead.)
Using copyItemAtURL:toURL:error and NSFileManagerDelegate seems impossible to obtain same informations.
How can I obtain same behaviour in 10.8 without rewriting code myself?
Does Apple know now it is simple awful to make same thing?
Might not be the answer you wish to hear[1], but wrap copyfile(3) in your own Obj-C wrapper. You should be able to calculate all you need using the callbacks, in particular the progress one. HTH.
[1] Quite a few APIs in this general area have been deprecated, and while some new APIs have been introduced they seem incomplete. Reasonable guess might be more is coming in 10.9...
Related
Currently, I'm trying to enable the cl_khr_3d_image_writes extension for OpenCL on my M1 Mac however the cl_kernel.h file is read-only and can't be written to. I've disabled SIP however the problem persists. What am I doing wrong?
It's not clear to me what editing the header file would achieve. Editing system headers is almost always a bad idea, and when you find yourself wanting to do that, it's usually a good idea to take a step back and think about what you really are trying to achieve. There's almost always a better way than editing a system header.
So, you want to use 3D image writes.
Does your device report support for this extension? This is the first thing to check, and you should always check this on the end user's system too before trying to use an extension or you'll have more difficult error handling to deal with down the line.
macOS supports OpenCL 1.2, which has direct support for the 3D image write functions. When creating your context, make sure you create a version 1.2 compatible context, not version 1.0/1.1.
In OpenCL 1.2, all you should need to do if the device supports the extension, is to enable it and call those built-in functions to perform the writes.
To enable use of the extension in your kernel, use #pragma OPENCL EXTENSION cl_khr_3d_image_writes : enable
I should point out that OpenCL is deprecated on macOS, and it is being replaced by Metal compute shaders. When developing new software, it's recommended that you use those instead.
I'm building an application with OpenGL ES 2.0 and SDL2 for Android. Is SDL_GL_GetProcAddress working with OpenGL ES 2.0 on Android? Also i know OpenGL ES 2.0 is a subset of OpenGL, so with this method can it run on desktop systems too?
From a quick browse of the SDL repository it should be.
SDL_video.c defines the implementation of SDL_GL_GetProcAddress simply to check that you've started OpenGL and then to call _this->GL_GetProcAddress, where _this is a global instance of the video driver.
SDL_androidvideo.c sets its GL_GetProcAddress to be Android_GLES_GetProcAddress, which is a preprocessor substitution for SDL_EGL_GetProcAddress.
So, so far: if you call SDL_GL_GetProcAddress, you'll get through to SDL_EGL_GetProcAddress.
SDL_egl.c implements SDL_EGL_GetProcAddress but declines to call eglGetProcAddress on Android. This looks like it's probably an error — the reason given is this bug but the status for that bug switched to 'Released' in June 2013, which I believe means that this has been fixed in Android for more than three years.
That aside, the fallback is to use SDL_LoadFunction, first with the direct function name, then with it proceeded by an underscore provided it's short enough to fit into the statically-declared buffer. Which this one is.
(so, caveat: SDL_GL_GetProcAddress is definitely not thread-safe, even if you've taken appropriate share group steps to use multiple GL contexts, but if you're writing an SDL program you probably don't care)
Android should be using the dlopen version of SDL_sysloadso so it looks like SDL_LoadFunction is implemented directly as a call to dlsym. Which has no issues that I'm aware of under Android.
So, in summary: yes, that call should work. It'll use the platform-specific dynamic library loader rather than the EGL call though it probably doesn't need to, but that's just an implementation detail.
I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
Would be usefull to see how things work but not sure on the legality of it
Most Mac apps are written using Cocoa in Objective-C; which, while it is a compiled language, means that there is a fair bit of information left over that could be used by a decompiler.
I'm not sure if there are a lot of decompilers out there that leverages this information, at least I haven't heard of any.
However, there are also another option; F-Script.
F-Script can be used to attach to an executable and explore its interfaces, while not as good as source, it can give you a pretty clear idea of how the executable is built, and how it operates.
As for the legality issue:
IANAL, but as far as I know, reverse-engineering for the purposes of compatibility is legal in many jurisdictions, and I can't imagine that decompiling an executable to look at its code is illegal, unless the specific EULA specifically prohibits it.
Edit: WRT Steam specifically, it is probably NOT written in Cocoa, but C# with some manner of .NET compatibility layer; and it's probably not a good place to start if you want to learn how to make applications for Mac OS X.
By far, the best Mac OS X disassembler I've used is Hopper available here:
http://www.hopperapp.com/
It will also convert the assembly to C pseudo code as best it can. It will generate code flow diagrams with blue lines (true blue, love it) for true and red for false paths.
It's The Mac OS reverse engineering tool. There are even Youtube videos that will show you how to use it.
If it's an open-source app, yes. Otherwise it's possible through decompilation but the output will be a real pain in the ass to look at. If you just want the protocols and the interfaces of categories and classes, have a look at class-dump.
I'm not aware of a nib decompiler.
Whether decompilation is legal: ask a lawyer. This may (and probably does) differ per jurisdiction.
Is it possible to view the source of a mac app?
Realistically, no. Sure, you might be a able to use a decompiler to get a peek, but the kind of output you'll get won't be easy to read. If you're asking this question, this route probably isn't going to be helpful to you.
Specifically interested in GUI and how the steam app for mac works
It's a good bet that it works about the same way that most other applications work. It might use custom controls to look different from a typical application that mostly uses the standard Cocoa controls. But underneath, just about any GUI application written for MacOS X will use the run loops, responder chain, and view hierarchy that Cocoa provide. The main exceptions would be applications that are built mostly using an alternate framework like OpenGL or WebKit.
Figure out what, specifically, the Steam application does that you'd like to do. Take a look at the tools that Cocoa provides to see if you can figure it out yourself; if not, ask about it here.
I'm working on a desktop application for OS X using Ruby-Tk, and I would like to provide an Apple Events interface for the application. This means that the application would define a dictionary of AppleScript commands that it would respond to (corresponding to Apple Events being sent to the application), and users/other applications could script the Ruby-Tk application with AppleScript commands. Other scripting languages support such functionality--Python through the py-aemreceive library at http://appscript.svn.sourceforge.net/viewvc/appscript/py-aemreceive/ and Tcl through the tclAE library at http://tclae.sourceforge.net/. I've been looking for similar functionality in Ruby and have come up empty.
One possible mechanism is the rubyobjc bridge, which provides a low-level interface between Ruby and Objective-C, but this gem appears to be little-used and is sorely lacking in examples and documentation, so I am not sure if this would be a fruitful path to pursue.
NB: MacRuby might work but it is not compatible with Tk, so that rules out MacRuby. Also, RubyOSA and rb-appscript are not what I am looking for--they allow Ruby to send Apple Events to other applications, not receive them.
In the absence of other alternatives, it appears I am going to have to write my own Ruby wrapper for the portions of the AppleEvent C API that I need: mainly AEInstallEventHandler and related functions. Fortunately Apple still supports this API even though it has been relegated to "legacy" status in Apple's developer docs (though, interestingly, it is not deprecated). I'll either integrate these functions via Ruby's ffi gem or, more likely, via Ruby's C API (which I still have to dig into); using the C API directly would reduce the need for dependencies on other gems/modules. If this goes well I will release it as a gem.
Regarding Donal Fellows' comment, my need is for custom AppleEvents--the ones supported via Tk in the docs he recommends can likely be accessed through calls to Tk from Ruby's Tk interface.
You might want to check the appscript library (note: Seems to only work with the OS X-provided Ruby), or try using MacRuby, which wraps pretty much everything of the APIs available in OS X, even the C ones.