Xojo Conferences
XDCMay2019MiamiUSA

Xcode 2.1 (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: CodeWarrior vs Xcode
Next thread: calling SetEntriesInAcl in a plugin crashes


macosx and unix paths   -   GOLD
  Xcode 2.1   -   Bob Delaney
   Re: Xcode 2.1   -   Bob Delaney
   Re: Xcode 2.1   -   Bob Delaney
   Re: Xcode 2.1   -   Bob Delaney
    Re: Xcode 2.1   -   Scott Wyatt
     Re: Xcode 2.1   -   Christian Schmitz
      Re: Xcode 2.1   -   dazz
   Re: Xcode 2.1   -   Bob Delaney
   Re: Xcode 2.1   -   Bob Delaney
   Re: Xcode 2.1   -   Will Leshner
   Re: Xcode 2.1   -   Joseph J. Strout
   Re: Xcode 2.1   -   Bob Delaney

Xcode 2.1
Date: 07.06.05 00:43 (Mon, 6 Jun 2005 18:43:32 -0500)
From: Bob Delaney
Using Xcode 2.1 it appears that the REALbasic Mach-O Plugin.xcode should be in:
/Library/Application Support/Apple/Developer Tools/Project
Templates/Dynamic Library/Carbon Dynamic Library/

Then give File:New Project. Under Dynamic Library click on Carbon
Dynamic Library. Then in the info box you see:
This project builds a REALbasic Mach-O Plugin.

I haven't tried building a plugin yet.

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

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

Re: Xcode 2.1
Date: 07.06.05 03:12 (Mon, 6 Jun 2005 21:12:54 -0500)
From: Bob Delaney
>Using Xcode 2.1 it appears that the REALbasic Mach-O Plugin.xcode
>should be in:
>/Library/Application Support/Apple/Developer Tools/Project
>Templates/Dynamic Library/Carbon Dynamic Library/
>
>Then give File:New Project. Under Dynamic Library click on Carbon
>Dynamic Library. Then in the info box you see:
>This project builds a REALbasic Mach-O Plugin.
>
>I haven't tried building a plugin yet.
>
>Bob


I built a Carbon Mach-O dylib with the just released Xcode 2.1. Then
Plugin Converter created a working plugin. No big problems.

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

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

Re: Xcode 2.1
Date: 07.06.05 03:54 (Mon, 6 Jun 2005 21:54:34 -0500)
From: Bob Delaney
>>Using Xcode 2.1 it appears that the REALbasic Mach-O Plugin.xcode
>>should be in:
>>/Library/Application Support/Apple/Developer Tools/Project
>>Templates/Dynamic Library/Carbon Dynamic Library/
>>
>>Then give File:New Project. Under Dynamic Library click on Carbon
>>Dynamic Library. Then in the info box you see:
>>This project builds a REALbasic Mach-O Plugin.
>>
>>I haven't tried building a plugin yet.
>>
>>Bob
>
>I built a Carbon Mach-O dylib with the just released Xcode 2.1. Then
>Plugin Converter created a working plugin. No big problems.
>
>Bob


As an experiment I tried building a Universal Binary. PluginMain gave
127 errors. Not a surprise.

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

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

Re: Xcode 2.1
Date: 07.06.05 04:54 (Mon, 6 Jun 2005 22:54:22 -0500)
From: Bob Delaney
>
>As an experiment I tried building a Universal Binary. PluginMain
>gave 127 errors. Not a surprise.
>
>Bob

I also should have said that the default installation of Xcode 2.1
using XcodeTools.mpkg does not install the SDKs necessary for
universal binaries. That is done by MacOSX10.4.Universal.pkg in the
Packages folder.

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

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

Re: Xcode 2.1
Date: 07.06.05 06:09 (Mon, 06 Jun 2005 22:09:29 -0700)
From: Scott Wyatt
The real (pun) test will be spending $1500 and seeing if RB 2005 can
produce working applications in two weeks. ;)

Seriously, Freescale has already said their compiled code works on the
Intel distros of OpenDarwin (non-GUI), but you cannot use the compiler
on the Intel hardware. I guess you keep a G4 around to compile the
Mach-O applications? I'm sure Freescale didn't get one of the Intel OS X
boxes, so they are limited to tests with OpenDarwin.

It does throw a kink or two in my plans. It just became harder to pitch
people on purchasing new Macs (however wrong they would be). If you
doubt the university or potential clients aren't going to step on the
brakes, you're kidding yourself.

* sigh *

I hope RB will let us know their initial test results. It's going to be
yet another difficult transition. We all know how well companies like
Quark make the last big move. At least Adobe seems happy. (I use
InDesign, anyway, for university flyers and brochures.)

Has Real already ordered their dozen or so Macintels? InteliMacs? What
do we call these things? I hope we get regular status reports over the
next year.

- Scott
(In other news, Steve Jobs announces Pixar will be doing animation by
hand in the future, since Disney has migrated to digital. "We won't use
what Disney or Microsoft uses." -- borrowed from a post elsewhere.)

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

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

Re: Xcode 2.1
Date: 07.06.05 20:10 (Tue, 7 Jun 2005 21:10:55 +0200)
From: Christian Schmitz
Scott Wyatt <<email address removed>> wrote:

> I hope RB will let us know their initial test results. It's going to be
> yet another difficult transition. We all know how well companies like
> Quark make the last big move. At least Adobe seems happy. (I use
> InDesign, anyway, for university flyers and brochures.)
>
> Has Real already ordered their dozen or so Macintels?

I ordered mine some hours ago.

As I'll have to change my current build system, this will be a bigger
change (new plugin format, mach-o plugins, XCode instead of
Codewarrior), this Intel CPUs are just a nice benefit :-)

Mfg
Christian

Re: Xcode 2.1
Date: 08.06.05 12:37 (Wed, 8 Jun 2005 13:37:50 +0200)
From: dazz

On 7 juin 05, at 21:10, Christian Schmitz wrote:

> I ordered mine some hours ago.
>
> As I'll have to change my current build system, this will be a bigger
> change (new plugin format, mach-o plugins, XCode instead of
> Codewarrior), this Intel CPUs are just a nice benefit :-)

glad to hear that from you. :)

good luck with porting MBS stuff to MacIntel ! ;)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

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

Re: Xcode 2.1
Date: 08.06.05 07:23 (Wed, 8 Jun 2005 01:23:06 -0500)
From: Bob Delaney
At 9:54 PM -0500 6/6/05, Bob Delaney wrote:
>As an experiment I tried building a Universal Binary. PluginMain
>gave 127 errors. Not a surprise.

I have now succeeded (with a big caveat at the end of this email) in
building a universal binary dylib using Xcode 2.1. I commented out
some sections of PluginMain.cpp, and made one insertion. No other
file had to be modified. Here are the commented out sections:

/*
#ifdef _MSC_VER
#include "winheader++.h"
#endif
*/

/*
#if TARGET_68K
#include <A4Stuff.h>
#include <SetupA4.h>
#endif
*/

/*
#if defined(MPW_CPLUS) || defined(MPW_C)
#define NOSTATICINIT 1
#endif
*/

/*
#if TARGET_OS_MAC
#ifndef powerc
#define USECALLSHELL
#endif
#endif
*/

/*
#ifdef USECALLSHELL
static REALproc buildEnvironmentShell(void *func)
{
short *glue;
REALproc proc;
unsigned long originalCode;
unsigned long unglue;
unsigned long pluginA4 = GetCurrentA4();

static int gRemainAllocCount;
static Ptr gRemainAllocPtr;

if (!func)
return nil;
if (func =eEALstandardGetter)
return REALstandardGetter;

originalCode = (unsigned long) func;
if (!gRemainAllocCount)
{
gRemainAllocCount = 8;
gRemainAllocPtr = NewPtr(8 * 52);
}

glue = (short *) gRemainAllocPtr;
gRemainAllocPtr += 52;
gRemainAllocCount--;
proc = (REALproc) glue;

unglue = (unsigned long) (glue + 17);

*glue++ = 0x2079; // movea.l $, A0
*glue++ = a4stack >> 16;
*glue++ = a4stack & 0xffff;
*glue++ = 0x210c; // move.l A4, -(A0)
*glue++ = 0x211f; // move.l (A7)+, -(A0)
*glue++ = 0x287c; // move.l #, A4
*glue++ = pluginA4 >> 16;
*glue++ = pluginA4 & 0xffff;
*glue++ = 0x2f3c; // move.l #, -(A7)
*glue++ = unglue >> 16;
*glue++ = unglue & 0xffff;
*glue++ = 0x23c8; // move.l A0, $
*glue++ = a4stack >> 16;
*glue++ = a4stack & 0xffff;
*glue++ = 0x4ef9; // jmp $
*glue++ = originalCode >> 16;
*glue++ = originalCode & 0xffff;

*glue++ = 0x2279; // movea.l $, A1
*glue++ = a4stack >> 16;
*glue++ = a4stack & 0xffff;
*glue++ = 0x2f19; // move.l (A1)+,-(A7)
*glue++ = 0x2859; // movea.l (A1)+, A4
*glue++ = 0x23c9; // move.l A1, $
*glue++ = a4stack >> 16;
*glue++ = a4stack & 0xffff;
*glue++ = 0x4e75; // rts

return proc;
}
#endif
*/

The insertion was due to one error at the line 2047 of PluginMain.cpp:

gResolverPPC = (void *(*)(const char *)) gResolver("ResolverPPC");

in the REALPluginMain procedure. The error was:

error: 'gResolverPPC' was not declared in this scope

The context for this offending line was:

#ifdef USECALLSHELL
unsigned long (*getA4stack)(void);

getA4stack = (unsigned long(*)(void)) resolver("getA4stackReference");
a4stack = getA4stack();
#else
#if TARGET_OS_MAC
#if CARBON
gResolverPPC = (void *(*)(const char *)) gResolver("ResolverPPC");
#else
gResolverPPC = (void *(*)(const char *))
CallUniversalProc((RoutineDescriptor *) gResolver, kThinkCStackBased
| RESULT_SIZE(SIZE_CODE(4)) | STACK_ROUTINE_PARAMETER(1,
SIZE_CODE(4)), "ResolverPPC");
#endif
#endif
#endif

So, from an earlier declaration, I inserted before the offending line:

void *(*gResolverPPC)(const char *entryName);

And that did it. The Make was successful. The resulting universal
binary dylib was 432 KB in size, and had an icon with a blue book
stacked askew on top of a green book. My original Carbon only dylib
was 244 KB in size, and had the same icon.

I did use the Plugin Converter to make an rbx plugin. But with that
in RB's Plugin Folder, RB quit on launch.

The caveat:

When I went back to the original non-binary Carbon dylib project and
did the commenting out, but did not insert the line
void *(*gResolverPPC)(const char *entryName);
the Make was successful, and the resulting plugin worked.

But when I did insert the line, the Make was successful, but the
resulting plugin caused RB to quit on launch.

Any suggestions?

Bob



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

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

Re: Xcode 2.1
Date: 08.06.05 08:28 (Wed, 8 Jun 2005 02:28:30 -0500)
From: Bob Delaney
At 1:23 AM -0500 6/8/05, Bob Delaney wrote:
>I have now succeeded (with a big caveat at the end of this email) in
>building a universal binary dylib using Xcode 2.1.

I found the problem. PluginMain.cpp cannot be edited after a certain
line. So earlier I replaced

#ifdef powerc
void *(*gResolverPPC)(const char *entryName);
#endif

by

void *(*gResolverPPC)(const char *entryName);

and removed that line from where I had originally inserted it.

Now both projects (Carbon only and Universal Binary) make their
dylibs successfully. The plugins from the dylibs both work with
REALbasic to make successful OS X projects.

But if I try to use the Universal Binary plugin with REALbasic to
make a Windows application, I get the message:
Cannot load Windows version of plugin, etc.

I suspect the RB software engineers can easily solve that problem.

I am impressed by the few changes that were needed to make a
universal binary dylib. Apple's software engineers get my praise.

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

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

Re: Xcode 2.1
Date: 08.06.05 14:59 (Wed, 8 Jun 2005 06:59:22 -0700)
From: Will Leshner

On Jun 8, 2005, at 12:28 AM, Bob Delaney wrote:

> But if I try to use the Universal Binary plugin with REALbasic to
> make a Windows application, I get the message:
> Cannot load Windows version of plugin, etc.
>
> I suspect the RB software engineers can easily solve that problem.

Are you expecting that your Universal Binary can be used for Windows
as well? It doesn't seem likely to me.

Re: Xcode 2.1
Date: 08.06.05 15:09 (Wed, 8 Jun 2005 09:09:35 -0500)
From: Joseph J. Strout
At 6:59 AM -0700 6/8/05, Will Leshner wrote:

>>But if I try to use the Universal Binary plugin with REALbasic to
>>make a Windows application, I get the message:
>>Cannot load Windows version of plugin, etc.
>>
>>I suspect the RB software engineers can easily solve that problem.
>
>Are you expecting that your Universal Binary can be used for Windows
>as well? It doesn't seem likely to me.

Will is quite right. A Macintosh "Universal Binary" is only
"Universal" on the Mac platform -- it contains both Mac/PowerPC code
and Mac/Intel code. It doesn't contain Windows code. A plugin
containing only such code would be a Mac-only plugin, and wouldn't be
usable on Windows or Linux.

It's still a good exercise though, since when we introduce support
for making Mac/Intel applications, only plugins with Mac/Intel code
will be usable in them. The exact details of this support are still
to be determined though, so don't worry about it too much yet.

Best,
- Joe

Re: Xcode 2.1
Date: 08.06.05 16:37 (Wed, 8 Jun 2005 10:37:43 -0500)
From: Bob Delaney
>At 6:59 AM -0700 6/8/05, Will Leshner wrote:
>
>>>But if I try to use the Universal Binary plugin with REALbasic to
>>>make a Windows application, I get the message:
>>>Cannot load Windows version of plugin, etc.
>>>
>>>I suspect the RB software engineers can easily solve that problem.
>>
>>Are you expecting that your Universal Binary can be used for
>>Windows as well? It doesn't seem likely to me.
>
>Will is quite right. A Macintosh "Universal Binary" is only
>"Universal" on the Mac platform -- it contains both Mac/PowerPC code
>and Mac/Intel code. It doesn't contain Windows code. A plugin
>containing only such code would be a Mac-only plugin, and wouldn't
>be usable on Windows or Linux.
>
>It's still a good exercise though, since when we introduce support
>for making Mac/Intel applications, only plugins with Mac/Intel code
>will be usable in them. The exact details of this support are still
>to be determined though, so don't worry about it too much yet.
>
>Best,
>- Joe
>
>--
>Joe Strout REAL Software, Inc.

It was late at night when everything worked, and I wasn't thinking right. :(

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

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