🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.mac.programmer.codewarrior
4 messages
4 total messages Started by Gordon Tillman Fri, 08 Dec 2000 21:33
Bad problem in MoreFilesExtras?
#1304
Author: Gordon Tillman
Date: Fri, 08 Dec 2000 21:33
46 lines
2735 bytes
Hi folks,

I had some code that was crashing on PPC processors running system 8.0
or 8.1.  I tracked it down to my MoreFilesExtras call to XGetVInfo.  In
that routine it makes a call to CallPBXGetVolInfoSync.  In
MoreFilesExtras.c they do this:

---- cut here ----

/*
** CallPBXGetVolInfoSync is the glue code needed to make
PBXGetVolInfoSync
** File Manager requests from CFM-based programs. Apple added
PBXGetVolInfoSync
** to InterfaceLib in Mac OS 8.5, so if __MACOSEIGHTFIVEORLATER is
defined,
** CallPBXGetVolInfoSync is defined back to PBXGetVolInfoSync.
**
** Non-CFM 68K programs don't needs this glue (and won't get it) because
** they instead use the inline assembly glue found in the Files.h
interface
** file.
*/


#if TARGET_API_MAC_CARBON || !TARGET_RT_MAC_CFM

 // Carbon builds and 68K builds don't need this glue
 #define CallPBXGetVolInfoSync PBXGetVolInfoSync

#else // TARGET_API_MAC_CARBON || !TARGET_RT_MAC_CFM

----- cut here ----

Well PBXGetVolInfoSync crashes 8.0 or 8.1 PPC macs.  But
CallPBXGetVolInfoSync  is just being redefined as a call to that
function if you are not building for Carbon or not building a CFM app.
Furthermore, the comment makes reference to the macro
MACOSEIGHTFIVEORLATER, but that macro is not used in this code logic,
and I cannot find it anywhere in the MacOS Support folder tree.

Has anyone else run into this problem??? What did you do to fix it?

Thanks a bunch,

Gordon Tillman (got@mindspring.com)
Re: Bad problem in MoreFilesExtras?
#1305
Author: meeroh
Date: Fri, 08 Dec 2000 21:44
36 lines
2473 bytes
In article <FtcY5.107$ph1.7187@e420r-atl1.usenetserver.com>, "Gordon 
Tillman" <got@mindspring.com> wrote:

>I had some code that was crashing on PPC processors running system 8.0 
>or 8.1.  I tracked it down to my MoreFilesExtras call to XGetVInfo.  
>In that routine it makes a call to CallPBXGetVolInfoSync.  In 
>MoreFilesExtras.c they do this:

[snip]

>Well PBXGetVolInfoSync crashes 8.0 or 8.1 PPC macs.  But 
>CallPBXGetVolInfoSync  is just being redefined as a call to that 
>function if you are not building for Carbon or not building a CFM app. 
>Furthermore, the comment makes reference to the macro 
>MACOSEIGHTFIVEORLATER, but that macro is not used in this code logic, 
>and I cannot find it anywhere in the MacOS Support folder tree.

I don't see what the problem is.

PBXGetVolInfoSync can't be called directly from CFM non-Carbon apps on 
Mac OS 8.0 and 8.1. MoreFiles gives you CallPBXGetVolInfoSync glue to 
use in those cases. 

It souns to me like you are running your code on Mac OS 8.0 or 8.1, and 
you are weak-linking against interface lib, and you are either making 
direct calls to PBXGetVolInfoSync, instead of using 
CallPBXGetVolInfoSync, or you are somehow causing MoreFiles to #define 
CallPBXGetVolInfoSync to PBXGetInfoSync (maybe by #defining 
TARGET_API_MAC_CARBON), but then doing something wrong (such as linking 
against InterfaceLib after you defined TARGET_API_MAC_CARBON).

Hth,

meeroh
-- 
To get random signatures put text files into a folder called "Random Signatures" into your Preferences folder.
Re: Bad problem in MoreFilesExtras?
#1306
Author: Gordon Tillman
Date: Fri, 08 Dec 2000 22:10
29 lines
2296 bytes
Hi Meeroh,

About this:

> It souns to me like you are running your code on Mac OS 8.0 or 8.1,
and
> you are weak-linking against interface lib, and you are either making
> direct calls to PBXGetVolInfoSync, instead of using
> CallPBXGetVolInfoSync, or you are somehow causing MoreFiles to #define
> CallPBXGetVolInfoSync to PBXGetInfoSync (maybe by #defining
> TARGET_API_MAC_CARBON), but then doing something wrong (such as
linking
> against InterfaceLib after you defined TARGET_API_MAC_CARBON).

I see what you are saying; however, in MoreFilesExtra.c it has:

#if TARGET_API_MAC_CARBON || !TARGET_RT_MAC_CFM
#define CallPBXGetVolInfoSync PBXGetVolInfoSync
#endif

Would the net result of this be: If building for Carbon OR if NOT
building a CFM app, then
#define CallPBXGetVolInfoSync PBXGetVolInfoSync

So then wouldn't a call to  CallPBXGetVolInfoSync get passed off to
PBXGetVolInfoSync for pretty much ANY regular PPC application that is
non-carbon?

--gordon
Re: Bad problem in MoreFilesExtras?
#1307
Author: meeroh
Date: Fri, 08 Dec 2000 22:39
30 lines
1958 bytes
In article <e0dY5.252$ph1.14679@e420r-atl1.usenetserver.com>, "Gordon 
Tillman" <got@mindspring.com> wrote:

>I see what you are saying; however, in MoreFilesExtra.c it has:
>
>#if TARGET_API_MAC_CARBON || !TARGET_RT_MAC_CFM
>#define CallPBXGetVolInfoSync PBXGetVolInfoSync
>#endif
>
>Would the net result of this be: If building for Carbon OR if NOT
>building a CFM app, then
>#define CallPBXGetVolInfoSync PBXGetVolInfoSync
>
>So then wouldn't a call to  CallPBXGetVolInfoSync get passed off to
>PBXGetVolInfoSync for pretty much ANY regular PPC application that is
>non-carbon?

No, because any PPC application is a CFM application, therefore 
TARGET_RT_MAC_CFM is always true for a PPC application, and therefore on 
PPC the above #if is the same as

#if TARGET_API_MAC_CARBON

which is the desired result...

Hth,

meeroh
-- 
To get random signatures put text files into a folder called "Random Signatures" into your Preferences folder.
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads