Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

new plugin format (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: Plugin SDK for Codewarrior 9
Next thread: Re: Control Focus


macosx and unix paths   -   GOLD
  new plugin format   -   Chad J McQuinn
   Re: new plugin format   -   Joseph J. Strout
   Re: new plugin format   -   Chad J McQuinn
   Re: new plugin format   -   Seth Willits
   Re: new plugin format   -   Chad J McQuinn
   Re: new plugin format   -   Seth Willits
   Re: new plugin format   -   Chad J McQuinn
   Re: new plugin format   -   Seth Willits
   Re: new plugin format   -   Joseph J. Strout
   Re: new plugin format   -   Chad J McQuinn
   Re: new plugin format   -   Joseph J. Strout
   Re: new plugin format   -   Chad J McQuinn
   Re: new plugin format   -   Joseph J. Strout
   Re: new plugin format   -   Chad J McQuinn

new plugin format
Date: 06.06.04 16:29 (Sun, 6 Jun 2004 10:29:39 -0500)
From: Chad J McQuinn
I have a few questions about the new plugin format.

First, I would like my output from codewarrior to pack these things
into the right directory structure to begin with. Looking at the plugin
converter, it looks like the format is as follows for what goes inside
"Build Resources"

1) For mac carbon/classic: the raw contents of the code resource,
inside a data fork. See below for a further question
2) For windows, the dll (not the results of the dll postlinker, which
puts it in a resource). Is this just exactly the result of building
with the plugin SDK as-is (i.e. no postlinking)?
3) For linux, I presume just the shared library.
4) For mach-o, the same as linux? Just a plain mach-o dylib exporting
the necessary symbols?

For putting the code resources for carbon/classic plugins into a data
fork, does anyone know of a post-linker that does this?

I'm sure I have other questions but this will get me started, if anyone
knows the answers to these. If there's some further documentation on
this that I have missed, feel free to point me to it.

Thanks,
-Chad

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 16:37 (Sun, 6 Jun 2004 10:37:21 -0500)
From: Joseph J. Strout
At 10:29 AM -0500 6/6/04, Chad J McQuinn wrote:

>I'm sure I have other questions but this will get me started, if
>anyone knows the answers to these. If there's some further
>documentation on this that I have missed, feel free to point me to
>it.

See the "Plugin Converter Read Me.txt" document in the same folder as
the converter. It's the documentation for the file hierarchy needed
for the new format.

HTH,
- Joe

Re: new plugin format
Date: 06.06.04 18:54 (Sun, 6 Jun 2004 12:54:23 -0500)
From: Chad J McQuinn
On Jun 6, 2004, at 10:37 AM, Joseph J. Strout wrote:

> At 10:29 AM -0500 6/6/04, Chad J McQuinn wrote:
>
>> I'm sure I have other questions but this will get me started, if
>> anyone knows the answers to these. If there's some further
>> documentation on this that I have missed, feel free to point me to
>> it.
>
> See the "Plugin Converter Read Me.txt" document in the same folder as
> the converter. It's the documentation for the file hierarchy needed
> for the new format.

Thanks, Joe. It looks like for carbon/classic, I can now just build a
shared library and use the contents of its data fork, rather than
having to build a code resource. Does that sound right? Building a
shared library vs. a code resource does leave me with a two-byte
difference in the header, but I'm not sure if that's significant or not
as I don't know anything about PEF internals.

-Chad

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 19:05 (Sun, 6 Jun 2004 11:05:00 -0700)
From: Seth Willits
On Jun 6, 2004, at 10:54 AM, Chad J McQuinn wrote:

>> See the "Plugin Converter Read Me.txt" document in the same folder as
>> the converter. It's the documentation for the file hierarchy needed
>> for the new format.
>
> Thanks, Joe. It looks like for carbon/classic, I can now just build a
> shared library and use the contents of its data fork, rather than
> having to build a code resource. Does that sound right? Building a
> shared library vs. a code resource does leave me with a two-byte
> difference in the header, but I'm not sure if that's significant or
> not as I don't know anything about PEF internals.

I'm not sure, but why risk it?


Seth Willits
------------------------------------------------------------------------
---
President and Head Developer of Freak Software - http://www.freaksw.com
REALbasic Guru at ResExcellence - http://www.resexcellence.com/realbasic

"All is not gold that glitters."
-- Miguel de Cervantes
------------------------------------------------------------------------
---

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 19:22 (Sun, 6 Jun 2004 13:22:48 -0500)
From: Chad J McQuinn

On Jun 6, 2004, at 1:05 PM, Seth Willits wrote:

> On Jun 6, 2004, at 10:54 AM, Chad J McQuinn wrote:

>> Thanks, Joe. It looks like for carbon/classic, I can now just build a
>> shared library and use the contents of its data fork, rather than
>> having to build a code resource. Does that sound right? Building a
>> shared library vs. a code resource does leave me with a two-byte
>> difference in the header, but I'm not sure if that's significant or
>> not as I don't know anything about PEF internals.
>
> I'm not sure, but why risk it?

What, exactly, did I risk by *asking* if it's the right thing to do?

It would be nice to just have the new plugin built from codewarrior,
rather than have to hunt things down from the finder, open them up with
the plugin converter, etc. I'm 99% of the way there, I just need to
nail down a few last details.

-Chad

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 19:30 (Sun, 6 Jun 2004 11:30:07 -0700)
From: Seth Willits
On Jun 6, 2004, at 11:22 AM, Chad J McQuinn wrote:

>> I'm not sure, but why risk it?
>
> What, exactly, did I risk by *asking* if it's the right thing to do?

Well that's certainly an interesting way to interpret what I wrote.
That's not what I meant. Why risk using a shared library? It's not the
"right" thing to do since now one or any documentation I've seen has
said to do that. The question is, why build a shared library and see if
it works if you know a code resource works and is the defined method of
creating a plugin?

> It would be nice to just have the new plugin built from codewarrior,
> rather than have to hunt things down from the finder, open them up
> with the plugin converter, etc. I'm 99% of the way there, I just need
> to nail down a few last details.

I see what you're asking now. I didn't understand the question the
first time.


Seth Willits
------------------------------------------------------------------------
---
President and Head Developer of Freak Software - http://www.freaksw.com
REALbasic Guru at ResExcellence - http://www.resexcellence.com/realbasic

"Yesterday we obeyed kings and bent our necks before emperors. But
today we kneel only to truth, follow only beauty, and obey only love."
-- Kahlil Gibran
------------------------------------------------------------------------
---

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 19:45 (Sun, 6 Jun 2004 13:45:55 -0500)
From: Chad J McQuinn
On Jun 6, 2004, at 1:30 PM, Seth Willits wrote:

> On Jun 6, 2004, at 11:22 AM, Chad J McQuinn wrote:
>
>>> I'm not sure, but why risk it?
>>
>> What, exactly, did I risk by *asking* if it's the right thing to do?
>
> Well that's certainly an interesting way to interpret what I wrote.
> That's not what I meant. Why risk using a shared library? It's not the
> "right" thing to do since now one or any documentation I've seen has
> said to do that. The question is, why build a shared library and see
> if it works if you know a code resource works and is the defined
> method of creating a plugin?

The point is that for the new plugin format, code resources are *not*
the "right" way. The plugin converter rips the resource out of an
old-style plugin and writes it to the data fork of a file--in fact it
has to, since the new plugin format is a virtual volume and these do
not support resource forks.

Furthermore, a code resource is nothing but a packaged shared library,
and in the docs for the new plugin format, the following appears with
the description of the Build Resources folder:

"includes the necessary shared libraries"

so i hardly think I am asking some off-the-wall question about using a
bizarre hack here.

-Chad

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 20:05 (Sun, 6 Jun 2004 12:05:19 -0700)
From: Seth Willits
On Jun 6, 2004, at 11:45 AM, Chad J McQuinn wrote:

> so i hardly think I am asking some off-the-wall question about using a
> bizarre hack here.

You're not. But RB is only expecting two formats the new rbx and the
old code resource. If you put a shared library into the plugins folder,
I wouldn't expect it to work.


Seth Willits
------------------------------------------------------------------------
---
President and Head Developer of Freak Software - http://www.freaksw.com
REALbasic Guru at ResExcellence - http://www.resexcellence.com/realbasic

"Time goes by so fast, people go in and out of your life. You must
never
miss the opportunity to tell these people how much they mean to you."
-- "Cheers"
------------------------------------------------------------------------
---

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 20:10 (Sun, 6 Jun 2004 14:10:43 -0500)
From: Joseph J. Strout
At 12:54 PM -0500 6/6/04, Chad J McQuinn wrote:

>Thanks, Joe. It looks like for carbon/classic, I can now just build
>a shared library and use the contents of its data fork, rather than
>having to build a code resource. Does that sound right?

I don't know. All our projects, to my knowledge, continue to build
code resources for the Mac targets, which the plugin converter then
converts as needed. (Hopefully William will chime in here if I'm
saying something incorrect -- he's more familiar with the new plugin
format than I am.)

Best,
- Joe

Re: new plugin format
Date: 06.06.04 20:47 (Sun, 6 Jun 2004 14:47:50 -0500)
From: Chad J McQuinn
On Jun 6, 2004, at 2:10 PM, Joseph J. Strout wrote:

> At 12:54 PM -0500 6/6/04, Chad J McQuinn wrote:
>
>> Thanks, Joe. It looks like for carbon/classic, I can now just build a
>> shared library and use the contents of its data fork, rather than
>> having to build a code resource. Does that sound right?
>
> I don't know. All our projects, to my knowledge, continue to build
> code resources for the Mac targets, which the plugin converter then
> converts as needed. (Hopefully William will chime in here if I'm
> saying something incorrect -- he's more familiar with the new plugin
> format than I am.)

OK. Actually it doesn't really matter whether it works for carbon
(which I think it does) because classic targets use headers inside the
resources (ahead of the PEF container). So the resource extraction
still needs to be done for that case because you can't put the header
in a plain shared library, at least not using codewarrior. The same
style of post-linking can just be done for both targets.

I've submitted a feature request to be able to build shared libraries
for all targets:
http://support.realsoftware.com/feedback/viewreport.php?
reportid=lkrkopun

-Chad

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 20:53 (Sun, 6 Jun 2004 14:53:21 -0500)
From: Joseph J. Strout
At 2:47 PM -0500 6/6/04, Chad J McQuinn wrote:

>I've submitted a feature request to be able to build shared
>libraries for all targets:
>http://support.realsoftware.com/feedback/viewreport.php?reportid=lkrkopun

But I'm confused. Why is it any harder to build a code resource than
it is to build a shared library? What do you mean by "the resource
has to be extracted" -- extracted from what, in what way? I believe
you simply set your target settings to stick the built code resource
into the appropriate place of the folder hierarchy, and that's all
there is to it. Clearly you believe some additional (manual) step is
needed -- can you explain what that is?

Best,
- Joe

Re: new plugin format
Date: 06.06.04 21:17 (Sun, 6 Jun 2004 15:17:32 -0500)
From: Chad J McQuinn
On Jun 6, 2004, at 2:53 PM, Joseph J. Strout wrote:

> At 2:47 PM -0500 6/6/04, Chad J McQuinn wrote:
>
>> I've submitted a feature request to be able to build shared libraries
>> for all targets:
>> http://support.realsoftware.com/feedback/viewreport.php?
>> reportid=lkrkopun
>
> But I'm confused. Why is it any harder to build a code resource than
> it is to build a shared library? What do you mean by "the resource
> has to be extracted" -- extracted from what, in what way? I believe
> you simply set your target settings to stick the built code resource
> into the appropriate place of the folder hierarchy, and that's all
> there is to it. Clearly you believe some additional (manual) step is
> needed -- can you explain what that is?

Well, looking at the plugin converter source, I guess you are right. I
was basing my ideas off of dumping the contents of a .rbx plugin (the
format I would like to get to as painlessly as possible). I assumed
this would be the format necessary for creating my own folder hierarchy
and converting it, but it's not.

The plugin converter looks at the files in the folder hierarchy to see
if you are using a data-based file (e.g. windows DLL) or a
resource-based one. If there is a PLCN, etc. resource, it extracts
that, otherwise it uses the data fork. I didn't realize that this check
was being done so I thought I had to dump to the data fork myself,
because that's what I saw when I dumped the .rbx file.

This still leaves me with the issue of having to convert the folder
hierarchy. I know, it's only a few clicks with the plugin converter,
but I'm *that* lazy. I want to build from CW and be done with it. I've
got the folder hierarchy set up automatically now. I just need to work
out the easiest way to automate getting it into a virtual volume.

The virtual volume format isn't document anywhere, is it? ;)

Thanks for the tips.

-Chad

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: new plugin format
Date: 06.06.04 22:33 (Sun, 6 Jun 2004 16:33:55 -0500)
From: Joseph J. Strout
At 3:17 PM -0500 6/6/04, Chad J McQuinn wrote:

>This still leaves me with the issue of having to convert the folder
>hierarchy. I know, it's only a few clicks with the plugin converter,
>but I'm *that* lazy. I want to build from CW and be done with it.
>I've got the folder hierarchy set up automatically now. I just need
>to work out the easiest way to automate getting it into a virtual
>volume.

I'm sure someone with sufficient motivation could make a postlinker
plug-in for CodeWarrior. But I wonder if there isn't an even easier
way, at least on the Mac... isn't it possible to set up an
AppleScript to run automatically after a build? If so, you could
have that run the plugin converter.

Best,
- Joe

Re: new plugin format
Date: 06.06.04 23:38 (Sun, 6 Jun 2004 17:38:42 -0500)
From: Chad J McQuinn
On Jun 6, 2004, at 4:33 PM, Joseph J. Strout wrote:

> At 3:17 PM -0500 6/6/04, Chad J McQuinn wrote:
>
>> This still leaves me with the issue of having to convert the folder
>> hierarchy. I know, it's only a few clicks with the plugin converter,
>> but I'm *that* lazy. I want to build from CW and be done with it.
>> I've got the folder hierarchy set up automatically now. I just need
>> to work out the easiest way to automate getting it into a virtual
>> volume.
>
> I'm sure someone with sufficient motivation could make a postlinker
> plug-in for CodeWarrior. But I wonder if there isn't an even easier
> way, at least on the Mac... isn't it possible to set up an AppleScript
> to run automatically after a build? If so, you could have that run
> the plugin converter.

I see you have underestimated my laziness. I've already made the plugin
converter scriptable. Problem solved.

(AFAIK it's not possible to run an applescript automatically from CW,
but there is the shell tool postlinker and the "osascript" command.)

Thanks again,
-Chad

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>