macOS Is 0xb0000000 Still The Documented Memorty Offset for...

[Warhaven]

... 3rd party frameworks? I've read in some older posts that when compiling 3rd party frameworks to be used in your program, that you should set the initial memory offset to 0xb0000000 in your compiler settings so it doesn't conflict with your main program, which runs initially at 0x00000000. I've done that and haven't run into any memory conflicts, yet, but I just wanted to be sure that this was still the proper offset. The posts I had read were from 2007, and I can't actually find the documentation referring to this...

Also, would switching to the GNUC99 (so I can declare my variables in for-loop-initialization -- makes the code look cleaner) compiler in XCode be problematic for this? I can't imagine why, but just want to be sure... if anyone knows.

Thanks.

 

[chown33]

Please post a reference (URL) to whatever you read that mentions this magic offset.

I'm not aware of any required offset for any 3rd-party frameworks. A specific offset doesn't really make sense, either.

The address space of any app will map libraries (frameworks) in as needed. If one framework is already residing at 0xb0000000, then no other library could reside there. So the notion that a library somehow needs a specific offset would fail after the first library was loaded to that offset.

If you're thinking of prebinding, which was a necessary (or at least optimizing) step on older apps and frameworks, that hasn't been needed for quite some time.


And I'm not aware of any reason why C99 would be a problem, for libraries or any other code. It's primarily a syntax change anyway.

 

[Warhaven]

Please post a reference (URL) to whatever you read that mentions this magic offset.

http://rentzsch.com/cocoa/embeddedFrameworks

If you're thinking of prebinding, which was a necessary (or at least optimizing) step on older apps and frameworks, that hasn't been needed for quite some time.


And I'm not aware of any reason why C99 would be a problem, for libraries or any other code. It's primarily a syntax change anyway.

That's probably what I'm thinking. I've never worked with frameworks or objective c before (I've been doing PHP for a very long time and very little actual Cocoa stuff), but while implementing the framework, I kept getting a memory crash. So, I looked around and found that tutorial. It did look rather dated, which is what prompted my question. In any event, after recompiling appscript using his suggestions, I stopped receiving the error.

[edit]

Just to give you an idea of my experience level with programming in general, I do it as a hobby not as a profession (aside from the occasional required shell script). So, I haven't received any training/schooling in unit testing or proper debugging for that matter. So... I apologize if I get some terminology mixed up and confuse you.

 

[chown33]

http://rentzsch.com/cocoa/embeddedFrameworks

That's from 2004, not 2007. At least that's how I interpret the "Tuesday, April 20, 2004" at the bottom of that article. To give a sense of timeframes:

10.3 Panther public release: October 24, 2003
10.4 Tiger public release: 29 April 2005
(Source: Wikipedia)
​

The article's downloadable project is definitely older than Xcode 2.4.1, because it asked to upgrade when I opened it. This was on OS 10.4.11 (the oldest bootable OS + Xcode I have conveniently available), so I wouldn't necessarily give it the full weight of being relevant to today's Xcode.

What Xcode and OS version are you compiling on?

I've never had a problem like that before, so now I'll have to look at the frameworks whose source I build myself. I may not get around to that for a while (at least 24 hrs).

UPDATE: I checked the Sparkle 1.1 framework's project file, and it doesn't have any magic offset at all. That's the only framework source that's easy for me to check. Any others I'll have to pull from storage.

Without looking at any of my frameworks, it's possible that the change you made is simply avoiding a crash by taking the lib out of the line of fire of some wild store. In other words, maybe it's only "working" in the sense of not crashing, not because it's fixing the real problem.

If you're just learning the language, then writing a framework may not be the best choice as a starting point.

 

[Warhaven]

What Xcode and OS version are you compiling on?

3.1.1 on Leopard 10.5, but I often take it home, where I'm using whatever the latest is and SL 10.6.

I've never had a problem like that before, so now I'll have to look at the frameworks whose source I build myself. I may not get around to that for a while (at least 24 hrs).

UPDATE: I checked the Sparkle 1.1 framework's project file, and it doesn't have any magic offset at all. That's the only framework source that's easy for me to check. Any others I'll have to pull from storage.

Only 3rd party framework I'm using is Appscript. I had stumbled on that tutorial while looking for how to embed the framework with my app.

Without looking at any of my frameworks, it's possible that the change you made is simply avoiding a crash by taking the lib out of the line of fire of some wild store. In other words, maybe it's only "working" in the sense of not crashing, not because it's fixing the real problem.

If you're just learning the language, then writing a framework may not be the best choice as a starting point.

Yeah, I'm fairly new to objective c. I'm not building a framework, though, but I am using the objc-appscript framework in my project which I had to download and compile. I'm porting a program I wrote in AppleScript Studio to pure Obj-C. I'm not fond of AppleScript, and it has been quirky at best when interacting with UI controls.

I would have avoided dealing with a 3rd party frameworks all together and just use Apple's own AppleScript Bridge, but I need to support OS X 10.4, and Apple's AS Bridge requires 10.5 or newer. So, I've been using objc-appscript.