| 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. (Likewise for unicode, see below.) |
| 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 Unicode |
|
Studio now comes in non-unicode and unicode versions. When Studio 5
is released, it will be unicode-only. For the most part your coding
won't change, but my coding has to change to handle 4-bytes-per-character
coming and going from Omnis, 2-bytes-per-character coming and going from
Windows unicode APIs, and 1-byte-per-character coming and going from APIs
that don't support unicode. On OS X, you need .n_external and .n_xcomp versions of externals and components for non-unicode, and you need .u_external and .u_xcomp versions of externals and components for unicode. On Windows the names continue to use the .dll file extension, so you can't always tell by looking at the file names, but Omnis knows the difference, and you may find a line in the Trace Log immediately after launching Studio that alerts you to the problem: C:\Program Files\Omnis Software\OS43U\external\stringJockey.DLL - This non-Unicode external cannot be used with the Unicode version A single compilation of an external cannot work with both the non-unicode and the unicode versions of Studio. You need separate versions for each. The release of Studio 5 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 |