 | Online |
 |
|
 |
Currently no members online:)
You are an anonymous user. You can register for free by clicking here |
There are 1 unlogged users online ! |
|
|
|
 | Posted by: gunne on Thursday, June 08, 2006 - 23:25
Submitted by gunne |
| | | | From MorphOS Developer Connection:
Right, we've had the know-how for doing this available for years already (refined by me and several other developers during that time up to now), however I see that there is a need for a simple skeleton one can easily adapt for one's own project.
Well, look no further, here it is (in the SDK Files section), a quick outline of the features/notes: MorphOS Developer Connection
About Nixskeleton:
o Multiple libbases, each opener gets their own private base and global data.
o A task will always get the same base, thus the library can be indirectly opened elsewhere through the same task and still get the right libbase.
o However this means callers should avoid sharing libbase across tasks (this is frowned upon anyway), as it'll lead to trouble!
o You can use libnix I/O and anything requiring constructors etc in the library.
o Full of comments (hopefully enough) to help you understand the magic involved.
o The skeleton uses SYSV (with r12base to be able to work its magic) functions, since this is the most likely candidate (it is however possible to adapt it for 68k entries, basically you have to change the global __restore_r13() function).
o You *can* *not* pass filedescriptors between caller and library, or free() memory allocated by the other etc, doing so will mean certain death, you have been warned! ;)
If you have any questions about the skeleton, how it works, how to use it etc, don't hesitate to ask... ;)
- CISC
| 
|
| | |
| Shared library skeleton supporting libnix I/O, constructors, etc... | Log-in or register a new user account | 0 Comments |
|
| Comments are statements made by the person that posted them.
They do not necessarily represent the opinions of the site editor. |
|
