Topic: Portability questions

[Crimson Wizard]

I have couple of questions regarding AGS engine portability.

1. If you are familiar with engine code you may know that it does not make use of container classes (aside from limited number of exceptions): it uses dynamic arrays at best (although in a quite unsafe way), and static arrays too (that explains object limits). I do not know what were CJ's considerations, but is there anything that would prevent us from using container classes like STL or boost in the engine code? Can there be any portability issues?

2. If I am not missing anything, plugins - in the way they are made now - can be used only under Windows. IIRC that was why JJS made some of the plugins built in engine.
Are there any ideas on how to change that? I am not asking of immediate implementation, maybe some thoughts for the future use?

[JJS]

About the plugins:

They can be loaded from disk on all platforms. There is code that deals with loading dynamic plugin libraries for Linux (+Android), OSX (+jailbroken iOS), Windows of course and PSP. The only tested code is for Windows, Android and PSP though because I haven't gotten around to write Makefiles for the plugins on the other systems. In theory the plugin system is fully platform independent though so there is really nothing to fix there.

The reason why I implemented the builtin plugin support is that iOS application that are in the market are not allowed to load dynamic libraries but everything has to be compiled into one binary. So without builtin plugins, no plugins could be used on iOS.

Edit: Of course plugins have to be recompiled for each platform. What I would really like to see are more open source plugins that could be put into the AGS repository so that they are available everywhere. This is the time to be as cool as Mr. Leafshade whose AGSBlend plugin is in the repo and thus available on all platforms.

[Crimson Wizard]

They can be loaded from disk on all platforms.

Well, this is one of the cases I am glad I was mistaken

[JJS]

About the use of the STL:

I see no problem in using standard library classes like std::vector instead of doing malloc/realloc for dynamic arrays. At the top of my head I could also not think of a platform that has g++ but no usable libstdc++ (Android had a poor STL support at first but now it is fully featured).

As for boost the situation might be different since it surely make use of more advanced features. I don't think it is usable on PSP for example (not that big of a deal but still).

[RickJ]

If someone were to make a TCP/IP Communication Plugin what lib should they use to make it cross platform compatible?  Also do we have source available for one already as a reference?

I also agree on making all of them open source.  We ought to put a statement saying so in the plugin programming guidelines. 

[JJS]

If you use standard BSD socket functions the code is as platform independent as it gets, no special library required.

Plugin sources can be found here: https://github.com/adventuregamestudio/ags/tree/e40b4095604b0e06f6c5004ff87a8541976ad864/Plugins
The AGSBlend plugin is fully available on the engine and editor side while the other two are engine-only at the moment.

[Crimson Wizard]

Crimson Necromancer here.

The reason why I implemented the builtin plugin support is that iOS application that are in the market are not allowed to load dynamic libraries but everything has to be compiled into one binary. So without builtin plugins, no plugins could be used on iOS.

I was wondering, do iOS marketing rules allow to write new files? If yes, heh, will this violate any rules, if the engine will have plugin libraries packed in the resources, and then unarchived to disk?
Also, I always wanted to know if it's possible to create dlls from memory. I found this article about doing this on Windows: http://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/

[JJS]

I don't know how this policy is enforced. Maybe they look at the system call imports and refuse the app if it uses library loading related APIs? Apps can at least write to their own (sandboxed) documents directory so theoretically they could unpack anything they like there.

That code you linked to wrote his own version of the operating systems DLL loader. If you place the library sections correctly in memory and allocate the data sections it of course works. That is the same way a user mode binary loader for e.g. an exploited game console loads programs. After you have loaded the library you can just get function pointers to the exports and jump to it.