Re: Backbone on Windows

[Richard Frith-Macdonald]

On 30 Oct 2005, at 01:17, Christopher Armstrong wrote:

> I've have been experimenting with Backbone apps
> (Prefs/Terminal/TextEdit), and I can confirm these things do  
> compile and
> run well on Windows. My question: is Windows a supported platform for
> the applications?

I very much doubt it ... I guess you would have to ask the individual  
authors.

> I have Preferences and TextEdit running under mingw, and I can compile
> and run Terminal under cygwin, with no apparent loss in  
> functionality. I
> have had to make some changes to things to get them (and others, e.g.
> Gorm) to work under windows.

That's good to hear.  Thanks for trying them out.

> The changes are small, but I've listed them below if anyone's
> interested:
>
> Patch #1
> --------
> There seems to be a bug in gnustep related to window deallocation,  
> where
> it tries to deallocate (I think) an NSWindow more than once. I've  
> tried
> in vain to locate it. A workaround to prevent GNUstep or any other  
> Objc
> program from dereferencing "hanging" pointers is to modify the gnu  
> objc
> runtime:
>
> in sendmsg.c, objc_msg_lookup change the following line:
>
> if (receiver)
>
> to
>
> if (receiver && (receiver->class_pointer)!=(void*)0xdeadface)
>
> It seems the class pointer is made to equal that hex number (DEADFACE)
> when objects are deallocated. I have my runtime like this, and I'm yet
> to experience issues.

Well, that means there is a memory management error somewhere ... and  
changing the runtime  to try to ignore it would be to attempt to hide  
the real bug (making it harder to find/fix the bug because the  
program would not crash when it should).  The patch wouldn't even  
work reliably because it depends on the memory location containing a  
particular value ... which it will do only until the deallocated  
memory is used for something else.  GNUstep-base sets the contents of  
objects to contain 'deadface' immediately before deallocation  
precisely in order that an attempt to use the deallocated object will  
crash the very first time it is used after deallocation, rather than  
risking the chance that it will randomly work a few times.

There are features to help locate memory allocation problems ...

You can hack an app to call [NSObject +enableDoubleReleaseCheck:] to  
turn on checking for objects being released too many times.  This may  
catch memory management problems at an earlier point (though still  
not necessarily in the actually problematic code).  See the NSObjeect  
documentation for details.

You can also use the NSZombieEnabled and NSDeallocateZombies  
environment variables (See the GNUstep base environment variable  
documentation for details) to help debugging with gdb.


> Patch #2
> --------
> The makefile for Terminal just needs one line changed to compile under
> cygwin:
>
> editing /System/Applications/Terminal/GNUmakefile
>
> add the following line:
>
> Terminal_OBJC_LIBS += -lutil -liconv
>
> which should allow proper linking.

Does this work under mingw32 too?

> I'd release patches, but the changes are small enough to do by  
> hand, and
> I need them tested first, esp. #1, as it's controversial enough.

Actually #1 is just wrong rather than controversial, so there is no  
way it would be accepted.  On the other hand, a patch that actually  
fixed the memory allocation problem would be very gratefully (and  
quickly) accepted.