Enable the use of existing iOS libraries about winobjc

[AhmadBaracat]

I think this is a great idea and would open the door to many libraries that does not support Windows. Do you think we, developers, can start working on it?

[Alovchin91]

The only issue I see is external library's processor architecture. This means iOS libraries would not run on x86-x64 machines, though Mac libraries should. The iOS Bridge compiler could analyze all the external imports in the code, and then the linker could create a section in the resulting PE file that lists all those imports. Then the stub code in the PE could call iOS Bridge Runtime to load each external iOS library and analyze its imports (now here I'm not sure how iOS library's import section looks like) and then patch them to point into the Runtime's functions. Much the same way Windows loader works.

[colincornaby]

A serious issue would be API support. A lot of libraries might try linking to API that's not there. For example, a library we ship tries to touch a lot of API that's not present. Even then, the behaviors could be different. It seems like it could be a lot more trouble than it's worth for a Windows native application.

Most libraries ship with x86 libraries in since the iOS Simulator is x86 (and x86-64), so that's not a serious problem.

[colincornaby]

If we're talking about binary libraries, existing binaries could do things like call into Mach or the iOS kernel functions (or even BSD functions) which probably won't be emulated or would be difficult to emulate for this API. For example, an API like Flurry might ask kernel level code for device configuration, and that's going to be very difficult to emulate through an API like this.

[Alovchin91]

Okay, I see. Let me split this issue into two then as it also contains another important suggestion: #20

[rhaning]

Thanks for the idea, we don't have any plans for supporting iOS binaries at this time.