basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] [PATCH] Patch for copying and pasting styled text in Basilisk II / SheepShaver

[Ronald P. R. <ron...@xs...>]

Please ignore that message. It was sent days ago about an issue that is now solved. It was held up because it was too large.

Ronald.  

----------------------------------------
Op 30 juni 2012, om 22:38, schreef Ronald P. Regensburg:

> This (attached) is what Howard sent me.
> 
> Ronald.
> 
> 
> Op 30 jun. 2012, om 22:05 heeft Charles Srstka het volgende geschreven:
> 
>> On Jun 30, 2012, at 3:03 PM, Ronald P. Regensburg wrote:
>> 
>>> Core 2 Duo iMac, 10.7.4 (64-bit Kernel and Extensions), SheepShaver with your patch running in 64-bit mode:
>>> 
>>> SimpleText (SheepShaver) -> TextEdit (host)
>>> Only plain text arrives (with incorrect accented characters)
>>> 
>>> TextEdit (host) -> SimpleText (SheepShaver)
>>> Only plain text arrives (with correct accented characters)
>>> 
>>> Tex-Edit Plus 3.0.2 (SheepShaver) -> TextEdit (host)
>>> Only plain text arrives (with incorrect accented characters)
>>> 
>>> TextEdit(host) -> Tex-Edit Plus 3.0.2 (SheepShaver)
>>> Only plain text arrives (with correct accented characters)
>>> 
>>> 
>>> I repeated with a previous (June 22, 2012) SheepShaver build, also in 64-bit mode, and the results are exactly the same.
>>> 
>>> I see no difference at all between the two builds with regard to copying styled text.
>>> 
>>> Could Howard have applied the patch incorrectly?
>> 
>> Could be that it’s still running the old clipboard code. Would you mind sending it to me so I could look it over?
>> 
>> Thanks,
>> Charles
> 
<SheepShaver.zip>------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
basilisk-devel mailing list
bas...@li...
https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

On Thu, Jul 5, 2012 at 2:29 AM, Charles Srstka <
bas...@ch...> wrote:

> On Jul 5, 2012, at 12:39 AM, Alexei Svitkine wrote:
>
> if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber10_5)
>> ... new API
>> else
>> ... old API
>>
>
> Is your new implementation strictly better than the clip_macosx.cpp one?
> Can you give a brief overview comparing them in terms of what works and
> what doesn't? This will help make it clear whether it makes sense to always
> prefer to use the new API code when running on 10.6 for 32-bit builds. (And
> hence whether it makes sense to consolidate them now like this.)
>
>
> Well, it’s definitely better than the clip_macosx.cpp in that the latter
> doesn’t run on 64-bit systems. I’ve also added a couple of features to it:
>
> 1. copy/paste styled text into and out of the emulator
>
> 2. copy/paste international text using non-Roman scripts into and out of
> the emulator
>
> As for the 10.6+ pasteboard API, that adds two features:
>
> 1. The ability to just say “lemme read/write an NSAttributedString off the
> pasteboard!” and have the OS do the conversion for you to and from whatever
> internal representation it’s using, instead of saying “Gimme some data of
> kUTTypeRTF and I hope that’s what OS X still uses!”
>
> 2. The fact that the API is just more current and is a complete
> replacement for the old one, and although the old API isn’t deprecated yet,
> you know how Apple is (Exhibit A: the fact that the implementation in
> clip_macosx.cpp no longer works). Basically, this is for future-proofing.
>

Okay, but clip_macosx.cpp would still be able to handle scrap types that
exist both under Classic and Mac OS X transparently (at least, on PPC or if
there is no byteswapping needed), correct? Ones that wouldn't get handled
without explicit support in clip_macosx64.mm. That's the big difference,
still, right?

I think there will also be problems compiling this combined file on 10.4,
for example, since it wouldn't have headers for the new APIs. That can be
worked around with additional ifdefs, but that gets hairy fast.

 Let's leave merging these off for now, but we can revisit that later.



>  Still, if you do think the autorelease pools are really required, I
>> suggest making a C++ scoped object that will alloc an autorelease pool in
>> its ctor and release it in its dtor, which will eliminate the need for
>> draining the pool at all the early return points.
>>
>>
>> Yeah, that could work.
>>
>
> Could you make that change? I think it would be much cleaner than all the
> early-return cleanup in your current patch.
>
>
> Sure thing. I think I’ll put the wrapper object in a header file so that
> it can be used elsewhere if people want to. This’ll be an Objective-C++
> header file and will only be includable by Objective-C++ code; do you have
> any preference whether to put #ifdef guards around it or just use #import?
>

My preference would be to still have ifdef guards. Thanks.


> Charles
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Charles S. <bas...@ch...>]

On Jul 5, 2012, at 12:39 AM, Alexei Svitkine wrote:

> if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber10_5)
> 	... new API
> else
> 	... old API
> 
> Is your new implementation strictly better than the clip_macosx.cpp one? Can you give a brief overview comparing them in terms of what works and what doesn't? This will help make it clear whether it makes sense to always prefer to use the new API code when running on 10.6 for 32-bit builds. (And hence whether it makes sense to consolidate them now like this.)

Well, it’s definitely better than the clip_macosx.cpp in that the latter doesn’t run on 64-bit systems. I’ve also added a couple of features to it:

1. copy/paste styled text into and out of the emulator

2. copy/paste international text using non-Roman scripts into and out of the emulator

As for the 10.6+ pasteboard API, that adds two features:

1. The ability to just say “lemme read/write an NSAttributedString off the pasteboard!” and have the OS do the conversion for you to and from whatever internal representation it’s using, instead of saying “Gimme some data of kUTTypeRTF and I hope that’s what OS X still uses!”

2. The fact that the API is just more current and is a complete replacement for the old one, and although the old API isn’t deprecated yet, you know how Apple is (Exhibit A: the fact that the implementation in clip_macosx.cpp no longer works). Basically, this is for future-proofing.

>> Still, if you do think the autorelease pools are really required, I suggest making a C++ scoped object that will alloc an autorelease pool in its ctor and release it in its dtor, which will eliminate the need for draining the pool at all the early return points.
> 
> Yeah, that could work.
> 
> Could you make that change? I think it would be much cleaner than all the early-return cleanup in your current patch. 

Sure thing. I think I’ll put the wrapper object in a header file so that it can be used elsewhere if people want to. This’ll be an Objective-C++ header file and will only be includable by Objective-C++ code; do you have any preference whether to put #ifdef guards around it or just use #import?

Charles

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

>
> if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber10_5)
>  ... new API
> else
> ... old API
>

Is your new implementation strictly better than the clip_macosx.cpp one?
Can you give a brief overview comparing them in terms of what works and
what doesn't? This will help make it clear whether it makes sense to always
prefer to use the new API code when running on 10.6 for 32-bit builds. (And
hence whether it makes sense to consolidate them now like this.)


> Still, if you do think the autorelease pools are really required, I
> suggest making a C++ scoped object that will alloc an autorelease pool in
> its ctor and release it in its dtor, which will eliminate the need for
> draining the pool at all the early return points.
>
>
> Yeah, that could work.
>

Could you make that change? I think it would be much cleaner than all the
early-return cleanup in your current patch.

-Alexei

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Charles S. <bas...@ch...>]

On Jul 4, 2012, at 11:33 PM, Alexei Svitkine wrote:

> What specific APIs are not available on Tiger that you're using in the new code?

I’m currently using the modern pasteboard API to read and write objects from the pasteboard. To make this file compatible with Tiger, I’d basically just have to wrap a few things like this:

if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber10_5)
	... new API
else
	... old API

I also used a few block-based APIs here and there — I could just go replace those with something else.

> How do you plan to consolidate them?

Well, if clip_macosx64.mm is made compatible with Tiger, we could just dump clip_macosx.cpp, rename clip_macosx64.mm to clip_macosx.mm, and add it to both targets.

> Btw, I glanced at your code and one comment I have is you seem to use autorelease pools a lot. I wonder if it's really necessary - can you just retain/release manually? Or are you calling APIs that autorelease stuff themselves?

Well, let’s say I want to read an object or two off the pasteboard. To do this, I’ll call -[NSPasteboard readObjectsForClasses:options:]. This method returns autoreleased objects — there’s no real way around it. Then, when I want to get a subset of a data or string object, the -subdataWithRange:, -substringWithRange:, etc. APIs return autoreleased objects as well. Plenty of other APIs are like this as well — it’s even a common design pattern to autorelease in your getter accessors, like so:

- (id)foo {
	return [[_foo retain] autorelease];
}

I’m not particularly fond of this pattern, but it is pretty much standard practice in the Cocoa world, and is also what Apple’s synthesized accessors do by default, as documented here:

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html%23//apple_ref/doc/uid/TP30001163-CH17-SW28

On top of all this, even when an API isn’t returning an autoreleased object, you never know what it’s doing internally. It might generate autoreleased objects, it might call other APIs that generate autoreleased objects, etc. Basically what it boils down to is that when you write Cocoa code, you pretty much have to accept that you’re going to get autoreleased objects. The trouble with Basilisk/SheepShaver is we’re running the emulated processor’s run loop, which means we’re never actually going to drop back down to the Cocoa application run loop, which means that the automatic draining that Cocoa does at the end of its internal run loop isn’t going to happen. What *that* means is that if we don’t catch these autoreleased objects in a pool and drain them before we exit, that stuff’s just going to sit on the heap forever and effectively leak.

And since I already had pools set up, I didn’t see much harm in using some autoreleased objects of my own here and there, just to reduce a little clutter in the code. If this is bothersome, I can go back and change some of those things — but we do need to have the pools.

> Re: your comment in the code about @autoreleasepool: I don't think we'll drop support for gcc any time soon, so the code will have to stay compatible with both, so no point adding a comment about a hypothetical scenario that's not going to happen.
> 
> Still, if you do think the autorelease pools are really required, I suggest making a C++ scoped object that will alloc an autorelease pool in its ctor and release it in its dtor, which will eliminate the need for draining the pool at all the early return points.

Yeah, that could work. If we ever did add support for LLVM/clang, we could also make some macros with #ifdefs that would expand to a scoped object with gcc or @autoreleasepool with clang (the nice thing about @autoreleasepool is that it is supposed to have significantly better performance than the NSAutoreleasePool objects).

Charles

Re: [B2-devel] 64-bit BasiliskII MacOSX ?

[Robert M. <mr...@gm...>]

On 7/4/12, Alexei Svitkine <ale...@gm...> wrote:
> I was able to build and successfully run a 64-bit BasiliskII under Mac OS X
> when building with the following config:
>
> ./configure --enable-sdl-video --enable-sdl-audio --disable-vosf
> --disable-jit-compiler

Yes, that is correct. I can also build and run a 64-bit BasiliskII
without JIT. But you really want JIT, because it's 10 times faster.

My work uses a lot of floating-point math, so I use the Whetstone
benchmark to evaluate performance. Here are some figures, in thousands
of Whetstone loops per second (Kwhets/sec):

 real 20-MHz 68030 with 882: 1330 Kwhets/sec
 real 33 MHz 68040	: 5570 Kwhets/sec
 real 60 Mhz PPC 601: 22,990 Kwhets/sec
 BasiliskII 64-bit, no JIT: 90,200 K whets/sec
 real 233 Mhz PPC G3: 109,300 Kwhets/sec
 SheepShaver 32-bit, JIT enabled: 303,000 Kwhets/sec
 SheepShaver 64-bit, JIT enabled: 328,500 Kwhets/sec
 BasiliskII 32-bit, JIT enabled: 890,000 Kwhets/sec

BasiliskII with its JIT compiler is like a "5.2 GHz 68040" or a "13
GHz 68030+882". In some applications, it is significantly faster than
the best SheepShaver emulation.

By comparison, the best SheepShaver can do is a 700 MHz PowerPC G3 or
a "857-MHz PowerPC 601". Notice also the tiny difference between
32-bit and 64-bit SheepShaver.

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

Thanks.

On Thu, Jul 5, 2012 at 12:13 AM, Charles Srstka <
bas...@ch...> wrote:

> Thanks. Here’s an updated patch.
>
> BTW, do you want me to try to make this code Tiger-compatible so we can
> reconsolidate the 32-bit and 64-bit versions? They’ve already diverged
> quite sharply in supported features, although the effects will only be seen
> on legacy systems. I could do it by adding a few checks here and there; it
> would make the code a bit uglier, but it’s doable.
>

What specific APIs are not available on Tiger that you're using in the new
code?

How do you plan to consolidate them?

Btw, I glanced at your code and one comment I have is you seem to use
autorelease pools a lot. I wonder if it's really necessary - can you just
retain/release manually? Or are you calling APIs that autorelease stuff
themselves?

Re: your comment in the code about @autoreleasepool: I don't think we'll
drop support for gcc any time soon, so the code will have to stay
compatible with both, so no point adding a comment about a hypothetical
scenario that's not going to happen.

Still, if you do think the autorelease pools are really required, I suggest
making a C++ scoped object that will alloc an autorelease pool in its ctor
and release it in its dtor, which will eliminate the need for draining the
pool at all the early return points.

-Alexei

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Charles S. <bas...@ch...>]

Thanks. Here’s an updated patch.

BTW, do you want me to try to make this code Tiger-compatible so we can reconsolidate the 32-bit and 64-bit versions? They’ve already diverged quite sharply in supported features, although the effects will only be seen on legacy systems. I could do it by adding a few checks here and there; it would make the code a bit uglier, but it’s doable. I would want to have someone with a Tiger machine and a working SheepShaver setup with some language packs installed to test it and make sure everything worked, though.



Charles

On Jul 4, 2012, at 10:49 PM, Alexei Svitkine wrote:

> Fixed here:
> 
> https://github.com/cebix/macemu/commit/dd30a26a7c9b1e462b6c1976df1763d635b72d09
> 
> On Wed, Jul 4, 2012 at 11:46 PM, Charles Srstka <bas...@ch...> wrote:
> The problem, as it were, actually lies with the original source file — it uses CRLF line endings. There are a couple of reasons we shouldn’t be doing that:
> 
> 1. This isn’t a Windows source file — it’s Mac/Unix, and it should be using LF line endings, not CRLF.
> 
> 2. CRLF line endings make ‘git apply’ light up like a Christmas tree — git seems to consider CRLF to be an error, and when it’s spewing a whitespace error for every single line in the entire file, the signal/noise ratio makes it effectively impossible to properly check the patch for legitimate errors.
> 
> Is there any particular reason this file is using CRLF?
> 
> Charles
> 
> On Jul 4, 2012, at 8:38 PM, Alexei Svitkine wrote:
> 
>> There seems to be a problem with your patch - it's deleting all lines in clip_macosx64.mm and re-adding them - even when the lines didn't change (like the comment at the top of the file). Perhaps an issue with different line-break characters?
>> 
>> Please send a patch that doesn't do that...
>> 
>> -Alexei
>> 
>> On Wed, Jul 4, 2012 at 9:35 PM, Alexei Svitkine <ale...@gm...> wrote:
>> Cool!
>> 
>> Changing clip_macosx64.mm to require 10.6+ is fine as long as we abandon the idea to eventually having 32-bit use that code too (since we want to keep supporting Tiger and friends). Which I'm okay with, but it does mean that the two implementations may diverge in the features they support.
>> 
>> -Alexei
>> 
>> 
>> On Wed, Jul 4, 2012 at 8:53 PM, Robert Munafo <mr...@gm...> wrote:
>> On 7/4/12, Charles Srstka <bas...@ch...> wrote:
>> > On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote:
>> >> Isn't this change going to affect 32-bit builds? You do not mention
>> >> doing any test for 32-bit at compile time, and you'd need to do that.
>> >
>> > Right now, there are two versions of the clipboard code — one source file
>> > that gets included for 32-bit builds, and one that gets included for 64-bit
>> > builds. All the changes in that patch were to the 64-bit source file only,
>> > and thus shouldn’t have any effect one way or another on 32-bit builds, so
>> > really the only thing that should break is trying to run the 64-bit version
>> > on Leopard (does anyone actually try to do that?).
>> 
>> Oh, okay, great! I think it's totally okay for users of old OS's like
>> Tiger to be using the 32-bit version of SheepShaver. (I did
>> benchmarks, and there is less than a 1% difference in speed.) Leopard
>> is kinda old by today's standards too, and I think most Leopard users
>> would go to Snow Leopard. But Tiger to Leopard is a bigger leap,
>> because more stuff got moved or changed.
>> 
>> --
>>   Robert Munafo  --  mrob.com
>>   Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
>> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

Fixed here:

https://github.com/cebix/macemu/commit/dd30a26a7c9b1e462b6c1976df1763d635b72d09

On Wed, Jul 4, 2012 at 11:46 PM, Charles Srstka <
bas...@ch...> wrote:

> The problem, as it were, actually lies with the original source file — it
> uses CRLF line endings. There are a couple of reasons we shouldn’t be doing
> that:
>
> 1. This isn’t a Windows source file — it’s Mac/Unix, and it should be
> using LF line endings, not CRLF.
>
> 2. CRLF line endings make ‘git apply’ light up like a Christmas tree — git
> seems to consider CRLF to be an error, and when it’s spewing a whitespace
> error for every single line in the entire file, the signal/noise ratio
> makes it effectively impossible to properly check the patch for legitimate
> errors.
>
> Is there any particular reason this file is using CRLF?
>
> Charles
>
> On Jul 4, 2012, at 8:38 PM, Alexei Svitkine wrote:
>
> There seems to be a problem with your patch - it's deleting all lines in
> clip_macosx64.mm and re-adding them - even when the lines didn't change
> (like the comment at the top of the file). Perhaps an issue with different
> line-break characters?
>
> Please send a patch that doesn't do that...
>
> -Alexei
>
> On Wed, Jul 4, 2012 at 9:35 PM, Alexei Svitkine <ale...@gm...
> > wrote:
>
>> Cool!
>>
>> Changing clip_macosx64.mm to require 10.6+ is fine as long as we abandon
>> the idea to eventually having 32-bit use that code too (since we want to
>> keep supporting Tiger and friends). Which I'm okay with, but it does mean
>> that the two implementations may diverge in the features they support.
>>
>> -Alexei
>>
>>
>> On Wed, Jul 4, 2012 at 8:53 PM, Robert Munafo <mr...@gm...> wrote:
>>
>>> On 7/4/12, Charles Srstka <bas...@ch...> wrote:
>>> > On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote:
>>> >> Isn't this change going to affect 32-bit builds? You do not mention
>>> >> doing any test for 32-bit at compile time, and you'd need to do that.
>>> >
>>> > Right now, there are two versions of the clipboard code — one source
>>> file
>>> > that gets included for 32-bit builds, and one that gets included for
>>> 64-bit
>>> > builds. All the changes in that patch were to the 64-bit source file
>>> only,
>>> > and thus shouldn’t have any effect one way or another on 32-bit
>>> builds, so
>>> > really the only thing that should break is trying to run the 64-bit
>>> version
>>> > on Leopard (does anyone actually try to do that?).
>>>
>>> Oh, okay, great! I think it's totally okay for users of old OS's like
>>> Tiger to be using the 32-bit version of SheepShaver. (I did
>>> benchmarks, and there is less than a 1% difference in speed.) Leopard
>>> is kinda old by today's standards too, and I think most Leopard users
>>> would go to Snow Leopard. But Tiger to Leopard is a bigger leap,
>>> because more stuff got moved or changed.
>>>
>>> --
>>>   Robert Munafo  --  mrob.com
>>>   Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
>>> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Charles S. <bas...@ch...>]

The problem, as it were, actually lies with the original source file — it uses CRLF line endings. There are a couple of reasons we shouldn’t be doing that:

1. This isn’t a Windows source file — it’s Mac/Unix, and it should be using LF line endings, not CRLF.

2. CRLF line endings make ‘git apply’ light up like a Christmas tree — git seems to consider CRLF to be an error, and when it’s spewing a whitespace error for every single line in the entire file, the signal/noise ratio makes it effectively impossible to properly check the patch for legitimate errors.

Is there any particular reason this file is using CRLF?

Charles

On Jul 4, 2012, at 8:38 PM, Alexei Svitkine wrote:

> There seems to be a problem with your patch - it's deleting all lines in clip_macosx64.mm and re-adding them - even when the lines didn't change (like the comment at the top of the file). Perhaps an issue with different line-break characters?
> 
> Please send a patch that doesn't do that...
> 
> -Alexei
> 
> On Wed, Jul 4, 2012 at 9:35 PM, Alexei Svitkine <ale...@gm...> wrote:
> Cool!
> 
> Changing clip_macosx64.mm to require 10.6+ is fine as long as we abandon the idea to eventually having 32-bit use that code too (since we want to keep supporting Tiger and friends). Which I'm okay with, but it does mean that the two implementations may diverge in the features they support.
> 
> -Alexei
> 
> 
> On Wed, Jul 4, 2012 at 8:53 PM, Robert Munafo <mr...@gm...> wrote:
> On 7/4/12, Charles Srstka <bas...@ch...> wrote:
> > On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote:
> >> Isn't this change going to affect 32-bit builds? You do not mention
> >> doing any test for 32-bit at compile time, and you'd need to do that.
> >
> > Right now, there are two versions of the clipboard code — one source file
> > that gets included for 32-bit builds, and one that gets included for 64-bit
> > builds. All the changes in that patch were to the 64-bit source file only,
> > and thus shouldn’t have any effect one way or another on 32-bit builds, so
> > really the only thing that should break is trying to run the 64-bit version
> > on Leopard (does anyone actually try to do that?).
> 
> Oh, okay, great! I think it's totally okay for users of old OS's like
> Tiger to be using the 32-bit version of SheepShaver. (I did
> benchmarks, and there is less than a 1% difference in speed.) Leopard
> is kinda old by today's standards too, and I think most Leopard users
> would go to Snow Leopard. But Tiger to Leopard is a bigger leap,
> because more stuff got moved or changed.
> 
> --
>   Robert Munafo  --  mrob.com
>   Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] 64-bit BasiliskII MacOSX ?

[Alexei S. <ale...@gm...>]

I was able to build and successfully run a 64-bit BasiliskII under Mac OS X
when building with the following config:

./configure --enable-sdl-video --enable-sdl-audio --disable-vosf
--disable-jit-compiler

(Looks like the issue is only with the JIT version for 64-bit BasiliskII.)

-Alexei

On Tue, Jul 3, 2012 at 10:01 PM, Alexei Svitkine
<ale...@gm...>wrote:

>
>
> On Tue, Jul 3, 2012 at 7:30 AM, Ronald P. Regensburg <ron...@xs...>wrote:
>
>> I noticed the commit "Use clip_macosx64.mm for BasiliskII 64-bit builds
>> too."
>>
>> However, I have never been able to build a working 64-bit BasiliskII
>> MacOSX. And as far as I know, no one has.
>>
>> In Snow Leopard I can build a 32-bit BasiliskII fine. Attempts to build a
>> 64-bit application result at best in a x86_64 application that crashes on
>> launch.
>>
>> Can a 64-bit BasiliskII MacOSX be build from current source? If so, how?
>>
>
> You're right, that build does not appear to run (though, it compiles and
> builds fine).
>
>  I'd be curious to know if that's also true for 64-bit Linux or not.
>
> -Alexei
>

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

There seems to be a problem with your patch - it's deleting all lines in
clip_macosx64.mm and re-adding them - even when the lines didn't change
(like the comment at the top of the file). Perhaps an issue with different
line-break characters?

Please send a patch that doesn't do that...

-Alexei

On Wed, Jul 4, 2012 at 9:35 PM, Alexei Svitkine
<ale...@gm...>wrote:

> Cool!
>
> Changing clip_macosx64.mm to require 10.6+ is fine as long as we abandon
> the idea to eventually having 32-bit use that code too (since we want to
> keep supporting Tiger and friends). Which I'm okay with, but it does mean
> that the two implementations may diverge in the features they support.
>
> -Alexei
>
>
> On Wed, Jul 4, 2012 at 8:53 PM, Robert Munafo <mr...@gm...> wrote:
>
>> On 7/4/12, Charles Srstka <bas...@ch...> wrote:
>> > On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote:
>> >> Isn't this change going to affect 32-bit builds? You do not mention
>> >> doing any test for 32-bit at compile time, and you'd need to do that.
>> >
>> > Right now, there are two versions of the clipboard code — one source
>> file
>> > that gets included for 32-bit builds, and one that gets included for
>> 64-bit
>> > builds. All the changes in that patch were to the 64-bit source file
>> only,
>> > and thus shouldn’t have any effect one way or another on 32-bit builds,
>> so
>> > really the only thing that should break is trying to run the 64-bit
>> version
>> > on Leopard (does anyone actually try to do that?).
>>
>> Oh, okay, great! I think it's totally okay for users of old OS's like
>> Tiger to be using the 32-bit version of SheepShaver. (I did
>> benchmarks, and there is less than a 1% difference in speed.) Leopard
>> is kinda old by today's standards too, and I think most Leopard users
>> would go to Snow Leopard. But Tiger to Leopard is a bigger leap,
>> because more stuff got moved or changed.
>>
>> --
>>   Robert Munafo  --  mrob.com
>>   Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
>> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

Cool!

Changing clip_macosx64.mm to require 10.6+ is fine as long as we abandon
the idea to eventually having 32-bit use that code too (since we want to
keep supporting Tiger and friends). Which I'm okay with, but it does mean
that the two implementations may diverge in the features they support.

-Alexei

On Wed, Jul 4, 2012 at 8:53 PM, Robert Munafo <mr...@gm...> wrote:

> On 7/4/12, Charles Srstka <bas...@ch...> wrote:
> > On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote:
> >> Isn't this change going to affect 32-bit builds? You do not mention
> >> doing any test for 32-bit at compile time, and you'd need to do that.
> >
> > Right now, there are two versions of the clipboard code — one source file
> > that gets included for 32-bit builds, and one that gets included for
> 64-bit
> > builds. All the changes in that patch were to the 64-bit source file
> only,
> > and thus shouldn’t have any effect one way or another on 32-bit builds,
> so
> > really the only thing that should break is trying to run the 64-bit
> version
> > on Leopard (does anyone actually try to do that?).
>
> Oh, okay, great! I think it's totally okay for users of old OS's like
> Tiger to be using the 32-bit version of SheepShaver. (I did
> benchmarks, and there is less than a 1% difference in speed.) Leopard
> is kinda old by today's standards too, and I think most Leopard users
> would go to Snow Leopard. But Tiger to Leopard is a bigger leap,
> because more stuff got moved or changed.
>
> --
>   Robert Munafo  --  mrob.com
>   Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Robert M. <mr...@gm...>]

On 7/4/12, Charles Srstka <bas...@ch...> wrote:
> On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote:
>> Isn't this change going to affect 32-bit builds? You do not mention
>> doing any test for 32-bit at compile time, and you'd need to do that.
>
> Right now, there are two versions of the clipboard code — one source file
> that gets included for 32-bit builds, and one that gets included for 64-bit
> builds. All the changes in that patch were to the 64-bit source file only,
> and thus shouldn’t have any effect one way or another on 32-bit builds, so
> really the only thing that should break is trying to run the 64-bit version
> on Leopard (does anyone actually try to do that?).

Oh, okay, great! I think it's totally okay for users of old OS's like
Tiger to be using the 32-bit version of SheepShaver. (I did
benchmarks, and there is less than a 1% difference in speed.) Leopard
is kinda old by today's standards too, and I think most Leopard users
would go to Snow Leopard. But Tiger to Leopard is a bigger leap,
because more stuff got moved or changed.

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Ronald P. R. <ron...@xs...>]

Terrific!

OSX 10.6 being the minimum version supported by clip_macosx64.mm should not be a problem for SheepShaver. It does not run well in 64-bit mode on 10.5 anyway. That is why the Info.plist file in SheepShaver sets 10.6 as the minimum system version for Intel 64-bit:

	<key>LSMinimumSystemVersionByArchitecture</key>
	<dict>
		<key>i386</key>
		<string>10.4.0</string>
		<key>ppc</key>
		<string>10.4.0</string>
		<key>x86_64</key>
		<string>10.6.0</string>
	</dict>

(I do not know how BasiliskII 64-bit would behave, we have not seen a working 64-bit BasiliskII yet, but I suppose similar would be appropriate.)

Ronald.

----------------------------------------
Op 4 juli 2012, om 22:03, schreef Charles Srstka:

This patch adds support for international text to Basilisk II / SheepShaver's clipboard support. Text copied on the host side is converted from Unicode to the format that the classic Mac OS Script Manager expects, with localized font variants used if they are available on the emulated system (unfortunately, if a localized font is not available, the text will render incorrectly due to the nature of the Script Manager). When text is copied on the emulated system, the script of the current font is used to determine the encoding of the text, and it is converted to Unicode to be pasted on the host side.

This patch supports copying and pasting text containing multiple scripts; for example, "EnglishČesky日本", where ranges (0, 7) and (8, 4) are Roman, (7, 1) is Central European, and (12, 2) is Japanese, can be freely copied and pasted back and forth between the host and emulated platforms, provided that the emulated platform has localized Central European and Japanese fonts installed.

In order to get this to work, I rewrote pretty much all of clip_macosx64.mm. The code now completely uses the Cocoa framework rather than CoreFoundation and Pasteboard Manager. Because this API now uses the Mac OS X 10.6+ version of the pasteboard API, the minimum version of OS X supported by clip_macosx64.mm is now 10.6. I think this shouldn't be a problem, since the 32-bit version still exists, but if this version needs to support older releases, let me know and I can add version-check code to do so. One of the benefits of using the modern API, however, is that our rich-text format is no longer hard-coded to the RTF format, which means we have automatic support for any other format used by the OS X pasteboard system, which as of Lion seems to include RTF, UTF-16 text, UTF-8 text, 'ut16'/'ustl', and others, and which may be supplemented by other formats in future releases of OS X.

I hope you find this patch useful.

Charles

<intltext.patch.zip>------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
basilisk-devel mailing list
bas...@li...
https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Charles S. <bas...@ch...>]

On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote:

> I don't care about 64-bit, but I want both BasiliskII and SheepShaver
> to run under MacOS 10.4 (Tiger).
> 
> Therefore, I might stay with the April 2012 version of the source code
> from now on.
> 
> Isn't this change going to affect 32-bit builds? You do not mention
> doing any test for 32-bit at compile time, and you'd need to do that.

Right now, there are two versions of the clipboard code — one source file that gets included for 32-bit builds, and one that gets included for 64-bit builds. All the changes in that patch were to the 64-bit source file only, and thus shouldn’t have any effect one way or another on 32-bit builds, so really the only thing that should break is trying to run the 64-bit version on Leopard (does anyone actually try to do that?).

Charles

Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Robert M. <mr...@gm...>]

I don't care about 64-bit, but I want both BasiliskII and SheepShaver
to run under MacOS 10.4 (Tiger).

Therefore, I might stay with the April 2012 version of the source code
from now on.

Isn't this change going to affect 32-bit builds? You do not mention
doing any test for 32-bit at compile time, and you'd need to do that.

On 7/4/12, Charles Srstka <bas...@ch...> wrote:
> This patch adds support for international text to Basilisk II /
> SheepShaver's clipboard support.
> [...]
> In order to get this to work, I rewrote pretty much all of clip_macosx64.mm.
> The code now completely uses the Cocoa framework rather than CoreFoundation
> and Pasteboard Manager. Because this API now uses the Mac OS X 10.6+ version
> of the pasteboard API, the minimum version of OS X supported by
> clip_macosx64.mm is now 10.6. I think this shouldn't be a problem, since the
> 32-bit version still exists, but if this version needs to support older
> releases, let me know and I can add version-check code to do so.
> [...]


-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Charles S. <bas...@ch...>]

This patch adds support for international text to Basilisk II / SheepShaver's clipboard support. Text copied on the host side is converted from Unicode to the format that the classic Mac OS Script Manager expects, with localized font variants used if they are available on the emulated system (unfortunately, if a localized font is not available, the text will render incorrectly due to the nature of the Script Manager). When text is copied on the emulated system, the script of the current font is used to determine the encoding of the text, and it is converted to Unicode to be pasted on the host side.

This patch supports copying and pasting text containing multiple scripts; for example, "EnglishČesky日本", where ranges (0, 7) and (8, 4) are Roman, (7, 1) is Central European, and (12, 2) is Japanese, can be freely copied and pasted back and forth between the host and emulated platforms, provided that the emulated platform has localized Central European and Japanese fonts installed.

In order to get this to work, I rewrote pretty much all of clip_macosx64.mm. The code now completely uses the Cocoa framework rather than CoreFoundation and Pasteboard Manager. Because this API now uses the Mac OS X 10.6+ version of the pasteboard API, the minimum version of OS X supported by clip_macosx64.mm is now 10.6. I think this shouldn't be a problem, since the 32-bit version still exists, but if this version needs to support older releases, let me know and I can add version-check code to do so. One of the benefits of using the modern API, however, is that our rich-text format is no longer hard-coded to the RTF format, which means we have automatic support for any other format used by the OS X pasteboard system, which as of Lion seems to include RTF, UTF-16 text, UTF-8 text, 'ut16'/'ustl', and others, and which may be supplemented by other formats in future releases of OS X.

I hope you find this patch useful.

Charles

Re: [B2-devel] 64-bit BasiliskII MacOSX ?

[Alexei S. <ale...@gm...>]

On Tue, Jul 3, 2012 at 7:30 AM, Ronald P. Regensburg <ron...@xs...>wrote:

> I noticed the commit "Use clip_macosx64.mm for BasiliskII 64-bit builds
> too."
>
> However, I have never been able to build a working 64-bit BasiliskII
> MacOSX. And as far as I know, no one has.
>
> In Snow Leopard I can build a 32-bit BasiliskII fine. Attempts to build a
> 64-bit application result at best in a x86_64 application that crashes on
> launch.
>
> Can a 64-bit BasiliskII MacOSX be build from current source? If so, how?
>

You're right, that build does not appear to run (though, it compiles and
builds fine).

I'd be curious to know if that's also true for 64-bit Linux or not.

-Alexei

Re: [B2-devel] 64-bit BasiliskII MacOSX ?

[Frank T. <fra...@gm...>]

Oh. I missed that. I have not needed to build Basilisk II in a while.

On Tue, Jul 3, 2012 at 12:19 PM, Robert Munafo <mr...@gm...> wrote:

> No, Frank, not SheepShaver. BasiliskII. Read the original question again.
>
> SheepShaver has a different JIT (it targets PowerPC rather than 68K)
> and thus manages to avoid the CMOV problem.
>
> On 7/3/12, Frank Trampe <fra...@gm...> wrote:
> > cambridge:~ admin$ file /Applications/SheepShaver-2.3/Support/SheepShaver
> > /Applications/SheepShaver-2.3/Support/SheepShaver: Mach-O 64-bit
> executable
> > x86_64
> >
> > I was able to do this on Snow Leopard early this year, I believe. It may
> be
> > that you did not have 64-bit versions of the dependencies installed when
> > you tried to build in 64-bit mode. Do you use MacPorts?
> >
> > On Tue, Jul 3, 2012 at 6:30 AM, Ronald P. Regensburg
> > <ron...@xs...>wrote:
> >> I noticed the commit "Use clip_macosx64.mm for BasiliskII 64-bit builds
> >> too."
> >>
> >> However, I have never been able to build a working 64-bit BasiliskII
> >> MacOSX. And as far as I know, no one has.
> >>
> >> In Snow Leopard I can build a 32-bit BasiliskII fine. Attempts to build
> a
> >> 64-bit application result at best in a x86_64 application that crashes
> on
> >> launch.
> >>
> >> Can a 64-bit BasiliskII MacOSX be build from current source? If so, how?
>
> --
>   Robert Munafo  --  mrob.com
>   Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
>

Re: [B2-devel] 64-bit BasiliskII MacOSX ?

[Robert M. <mr...@gm...>]

No, Frank, not SheepShaver. BasiliskII. Read the original question again.

SheepShaver has a different JIT (it targets PowerPC rather than 68K)
and thus manages to avoid the CMOV problem.

On 7/3/12, Frank Trampe <fra...@gm...> wrote:
> cambridge:~ admin$ file /Applications/SheepShaver-2.3/Support/SheepShaver
> /Applications/SheepShaver-2.3/Support/SheepShaver: Mach-O 64-bit executable
> x86_64
>
> I was able to do this on Snow Leopard early this year, I believe. It may be
> that you did not have 64-bit versions of the dependencies installed when
> you tried to build in 64-bit mode. Do you use MacPorts?
>
> On Tue, Jul 3, 2012 at 6:30 AM, Ronald P. Regensburg
> <ron...@xs...>wrote:
>> I noticed the commit "Use clip_macosx64.mm for BasiliskII 64-bit builds
>> too."
>>
>> However, I have never been able to build a working 64-bit BasiliskII
>> MacOSX. And as far as I know, no one has.
>>
>> In Snow Leopard I can build a 32-bit BasiliskII fine. Attempts to build a
>> 64-bit application result at best in a x86_64 application that crashes on
>> launch.
>>
>> Can a 64-bit BasiliskII MacOSX be build from current source? If so, how?

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[B2-devel] The JIT problems are related to (Re: 64-bit BasiliskII MacOSX ?)

[Robert M. <mr...@gm...>]

I concur. My 64-bit BaxiliskII compiles, but when run, it gives the error:

   x86-64 implementations are bound to have CMOV!
   Abort trap

I diagnosed this, and found it is because BasiliskII uses its runtime
JIT to try to determine if the CPU implements the CMOV instruction,
which fails because the JIT uses pre-compiled snippets of assembly
code that use the standard register set (i386 and GCC 4.x runtime
model). But when compiling for x86_64, the registers and runtime model
are all different, causing GCC's register save and restore
instructions to defeat the intended action of the JIT-compiled code
snippets. The CMOV works, but the moved result gets clobbered by GCC's
well-intentioned save and restores.

For a full explanation, see:

  http://mrob.com/pub/comp/basilisk-ii.html#temp_reg_bug

The solution is to stop using the GCC compiler at build time to
generate the snippets that the JIT uses at runtime. Instead, all the
snippets used for the JIT virtual machine should be assembled once,
and included as raw object code, in the source distribution. Then at
runtime, the JIT should strings these bits of object code together the
same way it does now. The difference is, we'll no longer be using the
compiler at build time to try to turn assembly language source into
80x86 object code.

This will also fix the incompatibility with new versions of GCC, with
LLVM/Clang, and any other future compilers or development systems. Who
knows, it might even work with Microsoft or Intel compilers some day
(-:

- Robert Munafo

On 7/3/12, Ronald P. Regensburg <ron...@xs...> wrote:
> I noticed the commit "Use clip_macosx64.mm for BasiliskII 64-bit builds
> too."
>
> However, I have never been able to build a working 64-bit BasiliskII MacOSX.
> And as far as I know, no one has.
>
> In Snow Leopard I can build a 32-bit BasiliskII fine. Attempts to build a
> 64-bit application result at best in a x86_64 application that crashes on
> launch.
>
> Can a 64-bit BasiliskII MacOSX be build from current source? If so, how?
>
> Ronald.

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] 64-bit BasiliskII MacOSX ?

[Frank T. <fra...@gm...>]

cambridge:~ admin$ file /Applications/SheepShaver-2.3/Support/SheepShaver
/Applications/SheepShaver-2.3/Support/SheepShaver: Mach-O 64-bit executable
x86_64

I was able to do this on Snow Leopard early this year, I believe. It may be
that you did not have 64-bit versions of the dependencies installed when
you tried to build in 64-bit mode. Do you use MacPorts?

On Tue, Jul 3, 2012 at 6:30 AM, Ronald P. Regensburg <ron...@xs...>wrote:

> I noticed the commit "Use clip_macosx64.mm for BasiliskII 64-bit builds
> too."
>
> However, I have never been able to build a working 64-bit BasiliskII
> MacOSX. And as far as I know, no one has.
>
> In Snow Leopard I can build a 32-bit BasiliskII fine. Attempts to build a
> 64-bit application result at best in a x86_64 application that crashes on
> launch.
>
> Can a 64-bit BasiliskII MacOSX be build from current source? If so, how?
>
> Ronald.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

[B2-devel] 64-bit BasiliskII MacOSX ?

[Ronald P. R. <ron...@xs...>]

I noticed the commit "Use clip_macosx64.mm for BasiliskII 64-bit builds too."

However, I have never been able to build a working 64-bit BasiliskII MacOSX. And as far as I know, no one has.

In Snow Leopard I can build a 32-bit BasiliskII fine. Attempts to build a 64-bit application result at best in a x86_64 application that crashes on launch.

Can a 64-bit BasiliskII MacOSX be build from current source? If so, how?

Ronald.

Re: [B2-devel] Various issues SheepShaver OSX

[Robert M. <mr...@gm...>]

Oh, that explains why I didn't see a problem: I created the eject fix and
sent it to the list, and when it was committed to the CVS, I didn't do a
CVS update because I already have the bug fix. Therefore, I didn't get the "Fix
inverted check from..." change.

I do remember noting that they had decided to fix the eject problem in a
different way than I had suggested, but was too busy to test their version.
(Although it wouldn't have done any good, because I would have only been
testing for proper ejecting when nocdron is true, as opposed to proper
mounting when nocdrom is false...)

On Saturday, June 30, 2012, Ronald P. Regensburg wrote:

> It took me a while to get (somewhat) familiar with the new GitHub
> repository. But I found where the problem with CD-ROMs not mounting in
> SheepShaver MacOSX started.
>
> It started April 21, 2012 with commit
> 6ee2964818c58fd6d7c512d9f61d2a9d343ebf20
> "Fix inverted check from my previous commit."
>
> The commit immediately before that:
> 2b348f7c4158022d8747ba7fe22c93197d6a059b
> "Don't start the Darwin media_thread if "nocdrom" pref is set."
> Mounts CD-ROMs alright.
>
> Not sure, but I suppose the "fix" was made by mistake because of the
> description
> "Don't start the Darwin media_thread if "nocdrom" pref is set."
> It could better have been described:
> Start the Darwin media_thread only if "nocdrom" pref is not set.l<https://lists.sourceforge.net/lists/listinfo/basilisk-devel>
>


-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com