Stupid question about if it's possible to link and create two separate executables

[Karlos]

I don't have the documentation handy, but there must be a way to create a Process pre v36 without trying to resort to this kind of thing.

Do you absolutely need pre v36 compatibility anyway?

[Karlos]

@Thorrin

That type of messaging would be extremely hit and miss under AmigaOS. You aren't supposed to use any absolute address (apart from when banging hardware regusters) and sharing variables in this way would be dangerous even if you could. There is no "ownership" possible - one thread may change the variable without the other being aware right in the middle of it doing something with it.

Fortunately amigaos does allow you to create message ports that can be registered (by name) with the system to allow interprocess communication by passing (by reference) messages between ports.

Still, neither of these seem particularly relevant to Jose's problem. There must be a way to create processes in pre v36 AmigaOS without having to load a segment list. How does CreateNewProc() do it?

[Karlos]

@bloodline.

Yeah, I wish. These days I don't seem to have the time to do any real coding (all this php/mysql/javascript stuff is interesting but hardly as much fun as C++) - and when I do have time I'm usually to bloody knackered.

Having a job killed my inner child :-(

[Karlos]

@Argo

Well, I was referring to exec's MsgPort/Message system. Your process can create a MsgPort and tell exec to add your new message port to its list of public ports, allowing other processes to look it up. The messages themselves are low level C structures that can be passed from one process to another process via these ports. There is no constraints on what that message can contain, so its quite a useful system. Processes can wait for messages to arrive at their ports and messages are automatically queued so that they are not lost if the process cannot process the message immediately.

A classic example is Intuition, which uses the system to send input events to the a window etc.

Arrex's ports are conceptually similar but not quite the same thing.

[Karlos]

@bloodline

Slight variation on that - simply create a struct that has all your shared globals in it and pass a pointer to that structure (via a Message) to the other task.

That struct could also contain a SignalSemaphore as part of its definition which would be used solve the concurrency issue.

[Karlos]

bloodline wrote:

Ahhh pointer magic then :-) :pint:

Well, this is only C after all. You have 2 options

1) allocate memory using exec or clib (the former is better for OS specific stuff of course)

2) create a constructor / destructor function pair, that in turn use (1) in order to achieve their task.

Either way, it always comes down to pointer magic. C++ offers various other approaches, except that too is also pointer magic, you just don't necessarily have to cast manually (depending on how you allocated your object,that is).

Let's face it, any raw memory handling for object memory will always involve some form of explicit/implicit pointer conversion.

[Karlos]

*drunkenly staggers, points and shouts angrily*

Truth? You can't handle the truth!

*collapses in stupor at keyboard and writes the next generation memory allocation mechanism accidently from a series of random face+keyboard interactions...*

[Karlos]

@bloodline

It isn't really needed as you can semaphore protect anything you choose to, the SignalSemaphore is completely general purpose. Hence you can allocate some memory and simply make sure you appropriately use the semaphore before accessing it. SignalSemaphores are quite flexible, you can get exclusive and read only (shared) locks etc.