# Help with a Windows port of a Ruby extension **URL:** \ **Category:** Ruby\ **Created:** [September 30, 2007, 9:55pm UTC](https://www.ruby-forum.com/t/help-with-a-windows-port-of-a-ruby-extension/115946 "2007-09-30T21:55:58Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![uberkorp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/7ab992/32.png) [@uberkorp](https://www.ruby-forum.com/u/uberkorp)\ **Post date:** [September 30, 2007, 9:55pm UTC](https://www.ruby-forum.com/t/help-with-a-windows-port-of-a-ruby-extension/115946/1 "2007-09-30T21:55:58Z")
I’m working on a game that’s in the early stages, and I want to make sure it runs on both OS X and Windows before I continue development. OS X is my primary OS, and it runs fine on that. But it crashes in Windows. The setup is this: the core of the game is written in Objective C, and I’m using Ruby for the scripting of the game. I wrote a very small Ruby extension to act as a bridge between the two (basically a wrapper around the Objective C game objects). Everything was fine, in OS X. In order to get it to compile in Windows, I had to write a separate extension to act as a wrapper around the Objective C /classes/ and do a hairy little dance to register them, because I don’t of a compiler flag in the standard gcc that’s an equivalent of Apple’s -undefined suppress, and I don’t want to link against all the main project files in the extension. And so, my current problem: it still runs fine in OS X, but it chokes when I try to create the Objective C object from within the Ruby extension. I create the Ruby class-wrapper object, register the Objective C class, test it thoroughly to make sure that it’s behaving as expected – it’s all fine when I do it from the main program. I even tried printing the pointer to the Obj-C class to make sure it’s not getting mangled, and it doesn’t seem to change at all. But all I get is garbage when I try to instantiate the class. I realize that my problem might likely turn out to have nothing to do with Ruby itself. In truth, the Ruby part seems to be behaving as expected. I pose the question here because I think I’m likely to find more Ruby people with experience in Objective C than Objective C people with experience in Ruby. And likewise for Windows. I’m using Ruby 1.8.6 on both machines. My Mac is running OS 10.4.10, and the Windows machine I’m using for development is … Windows XP Home. I’ll put the source up at [http://greay.phpwebhosting.com/shooter/shooter.r67.zip](http://greay.phpwebhosting.com/shooter/shooter.r67.zip) for people to look at, as well. ---
**Author:** ![uberkorp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/7ab992/32.png) [@uberkorp](https://www.ruby-forum.com/u/uberkorp)\ **Post date:** [October 1, 2007, 4:09am UTC](https://www.ruby-forum.com/t/help-with-a-windows-port-of-a-ruby-extension/115946/2 "2007-10-01T04:09:15Z")
On Sep 30, 2007, at 2:56 PM, Scott Mckie wrote: > ## extension to act as a bridge between the two (basically a wrapper don’t want to link against all the main project files in the get is and the Windows machine I’m using for development is … Windows XP Home. I’ll put the source up at [http://greay.phpwebhosting.com/shooter/shooter.r67.zip](http://greay.phpwebhosting.com/shooter/shooter.r67.zip) for people to look at, as well. > > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). Well, if you want Objective-C to be portable, you’ll have to build it with GNUStep/OpenStep instead of Cocoa. This can be difficult since many functions and libraries in Cocoa are not found in the GNU stuff. For the most part you can consider Objective-C to be OS X only, just as much of what is written for Windows uses Windows-only code that can’t be ported, or ported easily. Regardless, Windows doesn’t include the necessary runtime for Objective-C. You might want to re-write using another language instead of Obj-C to make it crossplatform. ---
**Author:** ![uberkorp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/7ab992/32.png) [@uberkorp](https://www.ruby-forum.com/u/uberkorp)\ **Post date:** [October 1, 2007, 5:05am UTC](https://www.ruby-forum.com/t/help-with-a-windows-port-of-a-ruby-extension/115946/3 "2007-10-01T05:05:19Z")
John J. wrote: > Well, if you want Objective-C to be portable, you’ll have to build it > with GNUStep/OpenStep instead of Cocoa. > This can be difficult since many functions and libraries in Cocoa are > not found in the GNU stuff. Cocoa might not be portable, but Objective C most certainly is. I’ve gotten Objective C code running on the Dreamcast. I don’t use Cocoa in this project. I’m using the Objective C runtime that comes with gcc and pretty much only use the base Object class. All my classes inherit from that. An earlier version of the game (before I wrote the Ruby extension) worked on Windows, and that was all in Objective C. So I don’t think that’s the problem. ---
**Author:** ![uberkorp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/7ab992/32.png) [@uberkorp](https://www.ruby-forum.com/u/uberkorp)\ **Post date:** [October 1, 2007, 6:27am UTC](https://www.ruby-forum.com/t/help-with-a-windows-port-of-a-ruby-extension/115946/4 "2007-10-01T06:27:51Z")
On Sep 30, 2007, at 10:05 PM, Scott Mckie wrote: > ## I don’t use Cocoa in this project. I’m using the Objective C runtime that comes with gcc and pretty much only use the base Object class. All my classes inherit from that. An earlier version of the game (before I wrote the Ruby extension) worked on Windows, and that was all in Objective C. So I don’t think that’s the problem. > > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). Well, sorry for the noise then. Not real familiar with Cygwin. Does it allow you to use \*nix style paths instead of windows style paths? Or is that even still an issue? I noticed you used DarwinPorts/MacPorts (whatever they’re calling it now) is it possibly some kind of path/dependency trouble? Maybe it’s expecting to see something at a path that isn’t what it expects? It’s interesting… ---
**Author:** ![uberkorp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/7ab992/32.png) [@uberkorp](https://www.ruby-forum.com/u/uberkorp)\ **Post date:** [October 1, 2007, 8:00pm UTC](https://www.ruby-forum.com/t/help-with-a-windows-port-of-a-ruby-extension/115946/5 "2007-10-01T20:00:33Z")
On Oct 1, 2007, at 12:27 PM, Scott Mckie wrote: > the C Data structure from /within/ the Ruby extension that I run into > causing the problem, or some weird differences between Apple’s and > GNU’s > Objective C runtimes. > > ## Very, very frustrating. > > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). Well, good luck! That sounds like uncharted waters. Maybe you’ll have to backtrack a bit and simplify the Ruby. See what it will respond to. ---
**Author:** ![uberkorp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/7ab992/32.png) [@uberkorp](https://www.ruby-forum.com/u/uberkorp)\ **Post date:** [October 1, 2007, 7:27pm UTC](https://www.ruby-forum.com/t/help-with-a-windows-port-of-a-ruby-extension/115946/6 "2007-10-01T19:27:53Z")
John J. wrote: > is it possibly some kind of path/dependency trouble? Maybe it’s > expecting to see something at a path that isn’t what it expects? > It’s interesting… The paths aren’t the issue. Cygwin lets you use \*NIX style paths, yes. But the game loads both Ruby extensions without hitch, and I’m able to instantiate at least one of them w/o problem. It’s when I try to access the C Data structure from /within/ the Ruby extension that I run into problems. The confusing thing is I can still access the C Data structure from the main program, and it will behave as expected. I’d thought that the problem might be some weird memory protection thing peculiar to Windows that was preventing me from accessing the class methods (virtual memory pages or some such junk), but I’ve done some more testing and /that/ doesn’t seem to be the case, thank god. So my last two ideas are that there are some compiler/linker flags that are causing the problem, or some weird differences between Apple’s and GNU’s Objective C runtimes. Very, very frustrating.