I'm trying to run some NSWindow functions from another thread on OSX. I am doing this via ctypes so need to find the library files.
dispatch_sync I found in libc.dylib but I can't find dispatch_get_main_queue, does anyone know the library that is in? Is it not in libc? I thought to use this based on here: Objective C Multi thread NSWindow alternative?
I also couldn't find the docs of the types used on opensource.apple can someone also help me find that for this Dispatch module.
dispatch_get_main_queue() is an inline function, so it doesn't end up in any library. It's compiled into every [Objective-]C/C++ file that uses it.
It compiles down to just (dispatch_queue_t)&_dispatch_main_q, more or less. That is, there's a global variable _dispatch_main_q and dispatch_get_main_queue() just returns its address, type cast to dispatch_queue_t.
On my 10.9.5 system, _dispatch_main_q is exported by /usr/lib/system/libdispatch.dylib.
Related
I want to run a function of Cocoa's Quartz Window Services on Mac called CGWindowListCopyWindowInfo using a library called objc from Rust, is it possible?
I can't figure out how to run function it with send_msg!.
First, you're linking to the Swift version of the API, you really want the objective C version.
Second, Objective-C is for "methods" on objects, that is why send_msg! takes a subject (obj). CGWindowListCopyWindowInfo is part of a "core" service, which means it's pretty much straight C. Now I don't know if there are bindings for that, apparently Servo once maintained CG bindings but it seems like they're deprecated. You can probably BYO as if you were binding to a regular C library (by hand or using bindgen).
I would recommend learning how macOS APIs and frameworks work first, though.
I was going through the Dinosaur book by Galvin where I faced the difficulty as asked in the question.
Typically application developers design programs according to an application programming interface (API). The API specifies a set of functions that are available to an application programmer, including the parameters that are passed to each function and the return values the programmer can expect.
The text adds that:
Behind the scenes the functions that make up an API typically invoke the actual system calls on behalf of the application programmer. For example, the Win32 function CreateProcess() (which unsurprisingly is used to create a new process) actually calls the NTCreateProcess() system call in the Windows kernel.
From the above two points I came to know that: Programmers using the API, make the function calls to the API corresponding to the system call which they want to make. The concerning function in the API then actually makes the system call.
Next what the text says confuses me a bit:
The run-time support system (a set of functions built into libraries included with a compiler) for most programming languages provides a system-call interface that serves as the link to system calls made available by the operating system. The system-call interface intercepts function calls in the API and invokes the necessary system calls within the operating system. Typically, a number is associated with each system call, and the system-call interface maintains a table indexed according to these numbers. The system call interface then invokes the intended system call in the operating-system kernel and returns the status of the system call and any return values.
The above excerpt makes me feel that the functions in the API does not make the system calls directly. There are probably function built into the system-call interface of the runtime support system, which are waiting for an event of system call from the function in the API.
The above is a diagram in the text explaining the working of the system call interface.
The text later explains the working of a system call in the C standard library as follows:
which is quite clear.
I don't totally understand the terminology of the excerpts you shared. Some terminology is also wrong like in the blue image at the bottom. It says the standard C library provides system call interfaces while it doesn't. The standard C library is just a standard. It is a convention. It just says that, if you write a certain code, then the effect of that code when it is ran should be according to the convention. It also says that the C library intercepts printf() calls while it doesn't. This is general terminology which is confusing at best.
The C library doesn't intercept calls. As an example, on Linux, the open source implementation of the C standard library is glibc. You can browse it's source code here: https://elixir.bootlin.com/glibc/latest/source. When you write C/C++ code, you use standard functions which are specified in the C/C++ convention.
When you write code, this code will be compiled to assembly and then to machine code. Assembly is also a higher level representation of machine code. It is just closer to the actual code as it is easier to translate to it then C/C++. The easiest case to understand is when you compile code statically. When you compile code statically, all code is included in your executable. For example, if you write
#include <stdio.h>
int main() {
printf("Hello, World!");
return 0;
}
the printf() function is called in stdio.h which is a header provided by gcc written specifically for one OS or a set of UNIX-like OSes. This header provides prototypes which are defined in other .c files provided by glibc. These .c files provide the actual implementation of printf(). The printf() function will make a system call which rely on the presence of an OS like Linux to run. When you compile statically, the code is all included up to the system call. You can see my answer here: Who sets the RIP register when you call the clone syscall?. It specifically explains how system calls are made.
In the end you'll have something like assembly code pushing some arguments into some conventionnal registers then the actual syscall instruction which jumps to an MSR. I don't totally understand the mechanism behind printf() but it will jump to the Linux kernel's implementation of the write system call which will write to the console and return.
I think what confuses you is that the "runtime-support system" is probably referring to higher level languages which are not compiled to machine code directly like Python or Java. Java has a virtual machine which translates the bytecode produced by compilation to machine code during runtime using a virtual machine. It can be confusing to not make this distinction when talking about different languages. Maybe your book is lacking examples.
I want to load special dll without execute dllmain function.
I think, set a breakpoint at dllmain can solve this problem.
But I don't know How can I do?
Also I want call dll's export function.
I have tried to use LoadLibraryEx with dont_resolve_dll_references, but it occurs error with dll's function call.
How can I solve this? Please give me your idea.
Thanks.
As explained in this question: Win32 API to enumerate dll export functions?
You can use LoadLibraryEx with the DONT_RESOLVE_DLL_REFERENCES flag, even though use of that flag is strongly discouraged.
If so you will likely have to free and reload the dll if you actually want to use it.
Well as explained here:
An optional entry point into a dynamic-link library (DLL). When the system starts or terminates a process or thread, it calls the entry-point function for each loaded DLL using the first thread of the process. The system also calls the entry-point function for a DLL when it is loaded or unloaded using the LoadLibrary and FreeLibrary functions.
calling the DllMain is an OS feature mandatory (although implementing that function is optional) if you use the standard way in loading and executing a dynamic library. So there is no official way in doing this.
Is there a recommended way to wrap a native c++ library by c++ cli?
Not sure if one size fits all, but yeah, it is largely a mechanical process. Your ref class wrapper should declare a private member that's a pointer to your native C++ class. Create the instance in the constructor. You'll need a destructor and a finalizer to delete that instance again.
Then for each function in the native C++ class you write a managed version of it. That's almost always a one-to-one call, you simply call the corresponding native method and let C++ Interop convert the arguments. Sometimes you have to write a bit of glue code to convert a managed argument to the native version of it, particularly if your native method uses 8-bit char* or structure arguments.
You'll find that standard pattern in code in my answer here. I also should mention SWIG, a tool that can automate it. Not sure how good it is, never used it myself.
Ok, well I have sorta of an odd situation. I have a two applications. One is the main application and the other is a helper bundle that is loaded during run time. What I want to do is to call a function defined within the main application from the bundle so that code does not have to be copied over. I have tried setting the header declaration for the function
NSString *TXReadableTime(NSTimeInterval date, BOOL longFormat);
within the helper bundle, but it still fails to compile. This is because one of my selectors is calling the function and the compiler is not finding it within the code. Only the header reference.
So I guess what my real question is, is there a way to have dynamic functions? One that is promised to the compiler, but is handled by a separate process. The helper bundle itself is allocated into memory so it has access to selectors of the main application, but I do not want to rewrite the function into a selector because it would require a lot of work.
Use -bundle_loader linker flag to specify the executable which will load the plugin. See ld man page, another Apple doc, and this informative blog post.