| Notes on Mac externals |
|
As Omnis 7 and Studio have evolved, externals for Windows have continued to
work with the newer releases in most cases. TCPTalk is the only one I can
think of where I have separate builds for Omnis 7 and Studio. Externals for the Mac, on the other hand, have run into stopping points along the way. Omnis 7 v3.1 was the first to run natively on PowerPC Macs, and externals for this version needed to be rebuilt as 'fat binaries' carrying both native PowerPC code fragments and 68K code resources. These rebuilt externals continued to work with older versions of Omnis 5 and 7 running on 68K Macs. The only kind of external for Omnis 7.3.x that will not work with Omnis Studio is a "7OBJ" external area. These act like fields in a window, and they need to be rewritten as external components for Studio. I only ran into this issue with some custom externals. All the rest of my Omnis 7 externals worked fine with Studio running in OS 9, and in 'classic mode' in OS X. Studio 3.1 was the first to run natively under OS X, and externals for this version needed to be rebuilt as 'carbon-based' code fragments. Studio 4.0 brought some internal Mac data types into line with their Windows counterparts. Structures with 2-byte elements changed to use 4-byte elements instead. That meant that all externals built for Mac Studio 3.1 needed to be recompiled with the new structures, and that no external could be built to work with both 3.x and 4.0. Most recently, Studio 4.2 for Mac became a universal binary, capable of running native on both PPC and Intel Macs. So for this version of Studio, all externals built for Studio 4.0 again needed to be recompiled as universal binaries themselves. Not all of my demos are up to date. If you want to try a demo with Studio 4.2 Mac, and the demo doesn't include a version for 4.2 (it should have a .n_external or .n_xcomp extension), send me an email to find out if I've ported that external yet. |
| Notes on Windows externals |
|
It turns out that Omnis 7.3.6.4 for Windows cannot see externals if
their names are too long. For example, 'StringJockey.DLL' was not
appearing in a call to Build externals list. Giving it a shorter
name (the developer who discovered this used 'Jockey.DLL') will
solve that problem. |
| Notes on renamed externals |
|
It's important that only one copy of any given external be placed
in the Omnis External or xcomp folder. Two copies of the same
external confuses Omnis - it may load one and call the other. So
when replacing externals with newer versions, don't rename the old
ones and leave them there, and make sure you see a 'Replace older
copy?' confirmation dialog - you won't, if the newer one has a
different name than the older one, and that's a danger sign. |
|
|
|
|
| Home | Externals List | Downloads |