basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

On Jun 18, 2012, at 12:04 PM, Robert Munafo wrote:

> Oh really? That's pretty cool. Does it have NSPICTImageRep?

Yep, and -[NSImage initWithData:] gets you an NSImage containing an NSPICTImageRep when you use it with PICT data. However, there’s a disclaimer in the documentation stating that because it’s not using QuickDraw, the image might not look *exactly* the same as the original. However, that disclaimer’s pretty much always been there, so I wouldn’t worry too much about it.

https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSPICTImageRep_Class/Reference/Reference.html

> I have Snow Leopard (10.6) and as discussed here:
> 
>  http://forums.macworld.com/index.php?/topic/121419-preview-cant-open-pict-files/
> 
> and here:
> 
>  http://blog.timac.org/?p=456
> 
> it won't display PICT files in QuickView unless I boot in 32-bit
> Kernel mode, and to open them into Preview I need to set the "Open in
> 32 Bit Mode" option in the Finder's info window for Preview.
> 
> Based on your report of reading PICT data on Lion, maybe Apple had to
> back-track on their policy.

Just tried it; -[NSImage initWithData:] works fine with PICT on 64-bit Snow Leopard too.

Charles

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

Oh really? That's pretty cool. Does it have NSPICTImageRep?

I have Snow Leopard (10.6) and as discussed here:

  http://forums.macworld.com/index.php?/topic/121419-preview-cant-open-pict-files/

and here:

  http://blog.timac.org/?p=456

it won't display PICT files in QuickView unless I boot in 32-bit
Kernel mode, and to open them into Preview I need to set the "Open in
32 Bit Mode" option in the Finder's info window for Preview.

Based on your report of reading PICT data on Lion, maybe Apple had to
back-track on their policy.

On 6/18/12, Charles Srstka <bas...@ch...> wrote:
> On Jun 18, 2012, at 1:41 AM, Robert Munafo wrote:
>
>> That might help a little bit -- but the main issue is on the host side.
>>
>> Apple does not provide 64-bit runtime libraries for any of Carbon,
>> such as is needed to convert PICT scrap data into another bitmap
>> format. In fact, all of QuickDraw is missing, and you can't even view
>> a PICT image on your Leopard (or later) Mac if you have it set to boot
>> with the 64-bit kernel (except by transferring the PICT data into an
>> emulator running an older Mac OS).
>
> Well, this doesn’t appear to be true; -[NSImage imageWithData:] seems to
> read PICT data on my Lion installation just fine. Opening the file with
> Preview also works.
>
> Charles

-- 
  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] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

And I do agree that building in 64-bit mode is an absolute necessity for
on-going compatibility.

On Mon, Jun 18, 2012 at 11:59 AM, Frank Trampe <fra...@gm...>wrote:

>
>
> On Mon, Jun 18, 2012 at 11:54 AM, Robert Munafo <mr...@gm...> wrote:
>
>> On 6/18/12, Josh Juran <jj...@gm...> wrote:
>> > Then wouldn't it make more sense to always build as 32-bit?  It's not
>> > like SheepShaver will ever even remotely need more than 4 GB of
>> > address space.
>>
>> We need 64-bit to work in Lion (10.7) and Mountain Lion (10.8). Snow
>> Leopard (10.6) is the last version that has any 32-bit runtime or a
>> 32-bit kernel.
>>
>
> Not exactly. Certain kernel-related things must run in 64-bit mode, but
> there is still i386 support.
>
> {
> cambridge:~ admin$ uname -v
> Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012;
> root:xnu-1699.26.8~1/RELEASE_X86_64
> cambridge:~ admin$ file /mach_kernel
> /mach_kernel: Mach-O universal binary with 2 architectures
> /mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
> /mach_kernel (for architecture i386): Mach-O executable i386
> }
>
>
>>
>> Apple is not Microsoft. They don't lift a finger for runtime binary
>> backward-compatibility.
>>
>> Certainly true.
>
>
>> > On Jun 17, 2012, at 11:41 PM, Robert Munafo wrote:
>> >> Apple does not provide 64-bit runtime libraries for any of Carbon,
>> >> such as is needed to convert PICT scrap data into another bitmap
>> >> format. In fact, all of QuickDraw is missing, and you can't even view
>> >> a PICT image on your Leopard (or later) Mac if you have it set to boot
>> >> with the 64-bit kernel (except by transferring the PICT data into an
>> >> emulator running an older Mac OS).
>>
>> --
>>  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] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

On Mon, Jun 18, 2012 at 11:54 AM, Robert Munafo <mr...@gm...> wrote:

> On 6/18/12, Josh Juran <jj...@gm...> wrote:
> > Then wouldn't it make more sense to always build as 32-bit?  It's not
> > like SheepShaver will ever even remotely need more than 4 GB of
> > address space.
>
> We need 64-bit to work in Lion (10.7) and Mountain Lion (10.8). Snow
> Leopard (10.6) is the last version that has any 32-bit runtime or a
> 32-bit kernel.
>

Not exactly. Certain kernel-related things must run in 64-bit mode, but
there is still i386 support.

{
cambridge:~ admin$ uname -v
Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012;
root:xnu-1699.26.8~1/RELEASE_X86_64
cambridge:~ admin$ file /mach_kernel
/mach_kernel: Mach-O universal binary with 2 architectures
/mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
/mach_kernel (for architecture i386): Mach-O executable i386
}


>
> Apple is not Microsoft. They don't lift a finger for runtime binary
> backward-compatibility.
>
> Certainly true.


> > On Jun 17, 2012, at 11:41 PM, Robert Munafo wrote:
> >> Apple does not provide 64-bit runtime libraries for any of Carbon,
> >> such as is needed to convert PICT scrap data into another bitmap
> >> format. In fact, all of QuickDraw is missing, and you can't even view
> >> a PICT image on your Leopard (or later) Mac if you have it set to boot
> >> with the 64-bit kernel (except by transferring the PICT data into an
> >> emulator running an older Mac OS).
>
> --
>  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] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

On 6/18/12, Josh Juran <jj...@gm...> wrote:
> Then wouldn't it make more sense to always build as 32-bit?  It's not
> like SheepShaver will ever even remotely need more than 4 GB of
> address space.

We need 64-bit to work in Lion (10.7) and Mountain Lion (10.8). Snow
Leopard (10.6) is the last version that has any 32-bit runtime or a
32-bit kernel.

Apple is not Microsoft. They don't lift a finger for runtime binary
backward-compatibility.

> On Jun 17, 2012, at 11:41 PM, Robert Munafo wrote:
>> Apple does not provide 64-bit runtime libraries for any of Carbon,
>> such as is needed to convert PICT scrap data into another bitmap
>> format. In fact, all of QuickDraw is missing, and you can't even view
>> a PICT image on your Leopard (or later) Mac if you have it set to boot
>> with the 64-bit kernel (except by transferring the PICT data into an
>> emulator running an older Mac OS).

-- 
  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] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

It would be nice to be able to copy and paste graphics between emulator and host, but I would rather see that efforts are directed first to clipboard integration for text. As it is now in SheepShaver on OSX, clipboard integration for text does not work at all in 64-bit mode and only works with severe limitations in 32-bit mode.

Ronald P. Regensburg.

Op 18 jun. 2012, om 14:00 heeft Alexei Svitkine het volgende geschreven:

> On Mon, Jun 18, 2012 at 2:41 AM, Robert Munafo <mr...@gm...> wrote:
>> That might help a little bit -- but the main issue is on the host side.
>> 
>> Apple does not provide 64-bit runtime libraries for any of Carbon,
>> such as is needed to convert PICT scrap data into another bitmap
>> format. In fact, all of QuickDraw is missing, and you can't even view
>> a PICT image on your Leopard (or later) Mac if you have it set to boot
>> with the 64-bit kernel (except by transferring the PICT data into an
>> emulator running an older Mac OS).
> 
> We could always do our own decoding of PICT data and convert it to a different format that is suitable to put on the host clipboard (in which case, the host wouldn't even need to be a Mac!)
> 
> For example, this open source library is able to parse PICTs:
> 
> http://www.paintlib.de/paintlib/
> 
> -Alexei
> 

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

On Mon, Jun 18, 2012 at 2:41 AM, Robert Munafo <mr...@gm...> wrote:

> That might help a little bit -- but the main issue is on the host side.
>
> Apple does not provide 64-bit runtime libraries for any of Carbon,
> such as is needed to convert PICT scrap data into another bitmap
> format. In fact, all of QuickDraw is missing, and you can't even view
> a PICT image on your Leopard (or later) Mac if you have it set to boot
> with the 64-bit kernel (except by transferring the PICT data into an
> emulator running an older Mac OS).
>

We could always do our own decoding of PICT data and convert it to a
different format that is suitable to put on the host clipboard (in which
case, the host wouldn't even need to be a Mac!)

For example, this open source library is able to parse PICTs:

http://www.paintlib.de/paintlib/

-Alexei

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

On Jun 18, 2012, at 4:33 AM, Josh Juran wrote:

> On Jun 17, 2012, at 11:41 PM, Robert Munafo wrote:
> 
>> That might help a little bit -- but the main issue is on the host  
>> side.
>> 
>> Apple does not provide 64-bit runtime libraries for any of Carbon,
>> such as is needed to convert PICT scrap data into another bitmap
>> format. In fact, all of QuickDraw is missing, and you can't even view
>> a PICT image on your Leopard (or later) Mac if you have it set to boot
>> with the 64-bit kernel (except by transferring the PICT data into an
>> emulator running an older Mac OS).
> 
> Then wouldn't it make more sense to always build as 32-bit?  It's not  
> like SheepShaver will ever even remotely need more than 4 GB of  
> address space.

This is unlikely to be a good idea, since one never knows if/when Apple will decide to stop supporting 32-bit binaries in some future version of OS X.

Charles

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

On Jun 18, 2012, at 1:41 AM, Robert Munafo wrote:

> That might help a little bit -- but the main issue is on the host side.
> 
> Apple does not provide 64-bit runtime libraries for any of Carbon,
> such as is needed to convert PICT scrap data into another bitmap
> format. In fact, all of QuickDraw is missing, and you can't even view
> a PICT image on your Leopard (or later) Mac if you have it set to boot
> with the 64-bit kernel (except by transferring the PICT data into an
> emulator running an older Mac OS).

Well, this doesn’t appear to be true; -[NSImage imageWithData:] seems to read PICT data on my Lion installation just fine. Opening the file with Preview also works.

Charles

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Josh J. <jj...@gm...>]

On Jun 17, 2012, at 11:41 PM, Robert Munafo wrote:

> That might help a little bit -- but the main issue is on the host  
> side.
>
> Apple does not provide 64-bit runtime libraries for any of Carbon,
> such as is needed to convert PICT scrap data into another bitmap
> format. In fact, all of QuickDraw is missing, and you can't even view
> a PICT image on your Leopard (or later) Mac if you have it set to boot
> with the 64-bit kernel (except by transferring the PICT data into an
> emulator running an older Mac OS).

Then wouldn't it make more sense to always build as 32-bit?  It's not  
like SheepShaver will ever even remotely need more than 4 GB of  
address space.

> On 6/17/12, Josh Juran <jj...@gm...> wrote:
>> I wrote a system extension called TESyncScrap that might help.  Prior
>> to Carbon, standard behavior for Mac apps was to wait until a layer
>> switch (i.e. bringing another application forward) to synchronize the
>> clipboard.  So if you didn't switch layers in the emulated Mac OS
>> after Cut/Copy or before Paste (when interchanging with the host OS),
>> you could get stale data.  Carbon apps always synchronize immediately
>> and therefore don't have this problem.
>>
>> When you install TESyncScrap, it patches TECut(), TECopy(), and
>> TEPaste() to synchronize immediately (as in Carbon), preventing stale
>> data when copying and pasting between an emulator and the host OS.
>>
>> TESyncScrap
>> <http://www.jjuran.org/hacks/TESyncScrap.mbin>
>>
>> TESyncScrap source
>> <https://github.com/jjuran/metamage_1/blob/master/mac/hacks/
>> TESyncScrap/TESyncScrap.cc>

[B2-devel] Fix crashes with SDL on linux

[Amadeusz S. <am...@as...>]

When I do ./configure --enable-sdl-video --enable-sdl-audio SheepShaver
crashes sooner or later after being started (usually before even ending
booting). I narrowed it down to be caused by changing cursors.

Some example of crashes:

SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
Using SDL/alsa audio output
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
SheepShaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Illegal instruction at 00002400, opcode = 000108c4
zsh: abort      ./SheepShaver


SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
Using SDL/alsa audio output
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
SheepShaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
SIGSEGV
  pc 0x45fc36
  ea 0x3dbc
 r0 03e00000   r1 01bffe00   r2 00000000   r3 00000000
 r4 41a67ab6   r5 00000000   r6 00000028   r7 000000b8
 r8 00000020   r9 00000000  r10 00000000  r11 00000001
r12 0000e38e  r13 0000ffff  r14 00000000  r15 499a0000
r16 419c54ea  r17 4d997082  r18 4d997082  r19 41ab9cbc
r20 4d997028  r21 4d9a2190  r22 41ab9cac  r23 00000000
r24 41a67ab6  r25 00000000  r26 fffffffe  r27 000021ee
r28 41b3df34  r29 51ed1170  r30 51e60000  r31 68fff000
 f0 0.00000   f1 0.00000   f2 0.00000   f3 0.00000
 f4 0.00000   f5 0.00000   f6 0.00000   f7 0.00000
 f8 0.00000   f9 0.00000  f10 0.00000  f11 0.00000
f12 0.00000  f13 0.00000  f14 0.00000  f15 0.00000
f16 0.00000  f17 0.00000  f18 0.00000  f19 0.00000
f20 0.00000  f21 0.00000  f22 0.00000  f23 0.00000
f24 0.00000  f25 0.00000  f26 0.00000  f27 0.00000
f28 0.00000  f29 0.00000  f30 0.00000  f31 0.00000
 lr 51e6d6e0  ctr 00000000   cr 40000088  xer 00000000
 pc 00003dbc fpscr 00000000
  0x    3d9c:  zsh: segmentation fault  ./SheepShaver

Configured with is a bit more informative
./configure --enable-sdl-video --enable-sdl-audio --disable-vosf

SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
Using SDL/alsa audio output
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
SheepShaver: /var/tmp/portage/x11-libs/libX11-1.5.0/work/libX11-1.5.0/src/xcb_io.c:178: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
zsh: abort      ./SheepShaver

So with attached patch it works fine, I tested it only on 64bit linux.

Amadeusz

Re: [B2-devel] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

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

That might help a little bit -- but the main issue is on the host side.

Apple does not provide 64-bit runtime libraries for any of Carbon,
such as is needed to convert PICT scrap data into another bitmap
format. In fact, all of QuickDraw is missing, and you can't even view
a PICT image on your Leopard (or later) Mac if you have it set to boot
with the 64-bit kernel (except by transferring the PICT data into an
emulator running an older Mac OS).

On 6/17/12, Josh Juran <jj...@gm...> wrote:
> I wrote a system extension called TESyncScrap that might help.  Prior
> to Carbon, standard behavior for Mac apps was to wait until a layer
> switch (i.e. bringing another application forward) to synchronize the
> clipboard.  So if you didn't switch layers in the emulated Mac OS
> after Cut/Copy or before Paste (when interchanging with the host OS),
> you could get stale data.  Carbon apps always synchronize immediately
> and therefore don't have this problem.
>
> When you install TESyncScrap, it patches TECut(), TECopy(), and
> TEPaste() to synchronize immediately (as in Carbon), preventing stale
> data when copying and pasting between an emulator and the host OS.
>
> TESyncScrap
> <http://www.jjuran.org/hacks/TESyncScrap.mbin>
>
> TESyncScrap source
> <https://github.com/jjuran/metamage_1/blob/master/mac/hacks/
> TESyncScrap/TESyncScrap.cc>
>
> Josh
-- 
  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] TESyncScrap (Thoughts on SheepShaver and Basilisk II)

[Josh J. <jj...@gm...>]

On Jun 15, 2012, at 4:12 PM, Lew Irwin/Studio Briefing wrote:

> I do not use the latest version of SheepShaver because of the  
> difficulty of
> transferring text to and from OS X, and even with the "official"  
> version
> that I am using now I have to transfer to Simple Text in OS 9  
> before I can
> paste into OS X.

I wrote a system extension called TESyncScrap that might help.  Prior  
to Carbon, standard behavior for Mac apps was to wait until a layer  
switch (i.e. bringing another application forward) to synchronize the  
clipboard.  So if you didn't switch layers in the emulated Mac OS  
after Cut/Copy or before Paste (when interchanging with the host OS),  
you could get stale data.  Carbon apps always synchronize immediately  
and therefore don't have this problem.

When you install TESyncScrap, it patches TECut(), TECopy(), and  
TEPaste() to synchronize immediately (as in Carbon), preventing stale  
data when copying and pasting between an emulator and the host OS.

TESyncScrap
<http://www.jjuran.org/hacks/TESyncScrap.mbin>

TESyncScrap source
<https://github.com/jjuran/metamage_1/blob/master/mac/hacks/ 
TESyncScrap/TESyncScrap.cc>

Josh

Re: [B2-devel] BasiliskII compilation issues

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

I've committed another change. Let me know if it works now.

On Sun, Jun 17, 2012 at 6:20 PM, Giulio Paci <giu...@gm...> wrote:

> Il 17/06/2012 18:42, Alexei Svitkine ha scritto:
> >
> >
> > On Sat, Jun 16, 2012 at 2:47 PM, Giulio Paci <giu...@gm...
> > <mailto:giu...@gm...>> wrote:
> >
> >     Il 15/06/2012 23:57, Alexei Svitkine ha scritto:
> >     > I've now landed a change that does that and also includes
> <signal.h>.
> >     > Let me know if it works for you now or if there are still issues.
> >
> >     It is still not working:
> >     sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this
> function)
> >
> >     I also have two warnings about "sig" and "strlcpy" implicit
> declaration.
> >     The first one is due to a wrong definition of mysignal. I do not know
> >     why I see the strlcpy warning (In config.h HAVE_STRLCPY has been
> defined
> >     to 1).
> >
> > I've landed another couple of changes. Can you try again?
>
> Still not working. :-( However if I include stropts.h (the only header I
> found on the kfreebsd system defining I_PUSH), compilation succeeds.
>
>
> ------------------------------------------------------------------------------
> 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] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Il 17/06/2012 18:42, Alexei Svitkine ha scritto:
> 
> 
> On Sat, Jun 16, 2012 at 2:47 PM, Giulio Paci <giu...@gm...
> <mailto:giu...@gm...>> wrote:
> 
>     Il 15/06/2012 23:57, Alexei Svitkine ha scritto:
>     > I've now landed a change that does that and also includes <signal.h>.
>     > Let me know if it works for you now or if there are still issues.
> 
>     It is still not working:
>     sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this function)
> 
>     I also have two warnings about "sig" and "strlcpy" implicit declaration.
>     The first one is due to a wrong definition of mysignal. I do not know
>     why I see the strlcpy warning (In config.h HAVE_STRLCPY has been defined
>     to 1).
> 
> I've landed another couple of changes. Can you try again?

Still not working. :-( However if I include stropts.h (the only header I
found on the kfreebsd system defining I_PUSH), compilation succeeds.

Re: [B2-devel] BasiliskII compilation issues

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

On Sat, Jun 16, 2012 at 2:47 PM, Giulio Paci <giu...@gm...> wrote:

> Il 15/06/2012 23:57, Alexei Svitkine ha scritto:
> > I've now landed a change that does that and also includes <signal.h>.
> > Let me know if it works for you now or if there are still issues.
>
> It is still not working:
> sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this function)
>
> I also have two warnings about "sig" and "strlcpy" implicit declaration.
> The first one is due to a wrong definition of mysignal. I do not know
> why I see the strlcpy warning (In config.h HAVE_STRLCPY has been defined
> to 1).
>
> I've landed another couple of changes. Can you try again?

-Alexei

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

[howard s. <how...@ho...>]

Hi all,

The sudden increase in activity on this ML makes for interesting 
reading. It looks like the development community is looking for an 
agenda? We, the maintainers of the http://www.emaculation.com
 website have ample experience in why and how SheepShaver is used by 
various groups of users. And have ample experience in what its 
shortcomings are. So, we would like to chime in from the user 
perspective.

First of, something about importance: In the 
discussion these past days, someone suggested that SheepShaver is not 
all that important because much old software can be run in Mini vMac. 
This is certainly not true for those who use SheepShaver on an Intel 
Mac, by far the largest group of SheepShaver users. After the demise of 
the Classic environment and later Rosetta, SheepShaver is the only way 
left to run Mac OS applications on an emulated PowerPC processor. Many 
Mac users simply need SheepShaver to keep some old applications running 
or to have access to files in formats that are not supported by today's 
Mac software. SheepShaver became a necessary tool that, as we know from 
the forum discussions and support questions, in some cases is even used 
to run irreplaceable software that is vital to professionals, 
businesses, or scientists.

Indeed. I was not saying that Mini vMac and DOSbox covered all or most of the SheepShaver bases. I was merely saying that SheepShaver is not a necessity for everybody's legacy application needs. A lot of software from the nineties was also available on DOS and Windows and is much easier to emulate that way. (We recently switched to the Windows version of a particular application on our Macintoshes in order to allow for more seamless integration via Wine.) On the Macintosh-only front, HyperCard has tended to be, in my experience, the classic Macintosh thing that people most want to emulate, and I have been able to recommend Mini vMac (and sometimes RunRev) for that.

The classic Macintosh did not start with a large user base. When one filters out people who are just enough satisfied with the OSX or Windows equivalents of the classic applications, the people who can successfully migrate to newer applications (like RunRev), and the people who just want HyperCard, the pool of potential contributors, developers, and users is relatively small.
 Someone called SheepShaver a niche 
product. While that in itself is true, we feel that some tender love and
 care (including some expansion in the feature set) could make it a bit 
less “nichy”. Looking around the Internet, one finds many failed attempts at getting SheepShaver running, or when it does run not providing the desired functionality.

Once again, I was not saying that SheepShaver was not important. It is very important to several work-flows that I maintain. I was merely trying to point out why emulation of a PowerPC Macintosh had not enjoyed the same sort of attention that other projects such as DOS emulation have drawn. The programming difficulties are much greater and the number of users much smaller. If there were millions of people very interested in doing this, there would be multiple projects and probably a commercial product or two.

>Yes we understand that. Our point would be: SheepShaver could be more helpful if it were more complete. 

 A point we would like to make is that we, as volunteer supporters/build providers, are not in favour of a diverging 
code base for the supported platforms.

Towards a better feature set for all supported hosts: 
-Improved CD/DVD handling. 

Like an eject key-stroke for disk images?
>And real CD's. While changing images would be nice (changing cd's is not well supported), we were also thinking about being able to read other formats besides data cd-roms. Audio is not read correctly on all platforms, while DVD's are not supported at all.

 
-USB support. 
-Video acceleration on the host. 


Which applications (games?) that you use have seemed to need this?
>Perhaps that needs to be rephrased: support for OpenGL etc.
 -Memory management allowing running Mac OS above 9.0.4. 

-More opcodes supported, allowing more applications to work. (Office comes to mind). 

I still use Word 5.1a on occasion without problems. Which version of Office causes problems?
>Office 98 and 2001 (all applications that are included in both) run into trouble. Some seem to think this has to do with the lack of virtual memory, but there are also signs that it is related to some opcodes not being supported.

 Also, are you sure that you aren't compiling with the PPC_REENTRANT_JIT flag set to 1? That disables a number of operations that are supported.
>We compile with the default settings, if that setting is 1, then Yes. We should check. 


-Improve networking, including Appletalk. 
-Improve communication to serial/parallel ports.
-A
 possibility to launch a SheepShaver built-in preferences editor without
 the emulator starting (by holding a modifier key?). That would make a 
separate external preferences editor superfluous.

Wouldn't you prefer to have these separate? We actually disabled the configuration editor in our environment. It is very rare that one wishes to tweak a working configuration, and adding another step to start-up seems unnecessary.
>This is more an issue for the OSX build, as that is the only one with built-in editor, which can only be opened after SheepShaver started. We would like to get rid of all the separate prefs editors floating around and a unified integrated solution would be great, specially if it could be started to configure SheepShaver without actually starting SheepShaver. The current GTK prefs editor in Linux does that. (But it has no "Save" option, it will always start SheepShaver or not save changes.)

 -Improve SCSI support.

As in allowing SheepShaver to interact with real SCSI devices? This would be nice, certainly, but might produce some messy conflicts with host operating system drivers if enabled by default.
>Yes, SCSI support was available in the old BasiliskII (build 142, 2001) for Windows through the ASPI driver. Perhaps that old code could point a way?


 Specific for OSX: 
-Clipboard exchange for text in 64-bit mode SheepShaver (it currently doesn’t work at all in 64-bit mode.) 
-Possibility to compile/build SheepShaver in MacOSX 10.7.x (Lion) and future versions. 


That requires reworking lots of assembly that llvm dislikes. And I am not sure what llvm likes.
>That's where your expertise must provide the answer, we wouldn't know ;-)
 
-Solution
 to the weird color problems on Intel Mac after SheepShaver window has 
been minimized or hidden and is brought back in view. (Possibly a SDL 
issue.)

Specific for Windows: 
-Replace the reliance on the cdenable.sys cd rom driver for CD support. It currently doesn’t work on 64-bit hosts. 
-Replace
 the reliance on the BasiliskII Ethernet driver with for example 
WinPcap, as it currently doesn’t run on 64-bit hosts (requiring driver 
signing).
-Replace reliance on Cygwin to build for Windows.

Would you prefer to get X11 from Windows Services for UNIX?
> Never tried that in Windows, but I guess it would take too much from the average user to go down that path. Also, is this a future-proof concept?
 
>Thanks!
>Howard


Best regards,
Ronald P. Regensburg and Howard Spoelstra
 		 	   		  


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] Thoughts on SheepShaver and Basilisk II

[C.W. B. <com...@ho...>]

I know a few games work better with 3D rendering. Pushing OpenGL to the host, and Glide through an OpenGL wrapper will be the easiest, with RAVE support (Descent II) being the hardest.

As for controllers: There's currently no way to use controllers on SheepShaver/Basilisk II. The easiest way to work with OS 8.1 and higher is to pass a USB controller from the host OS to the emulated OS. This leaves out games that don't use InputSprocket, though, as well as people trying to run earlier versions of Mac OS. Perhaps finding a common game pad/joystick that old games support and emulating that, with an InputSprocket extension to more fully use controllers.
On Jun 16, 2012, at 2:59 PM, Frank Trampe wrote:

>  
> -USB support. 
> -Video acceleration on the host. 
> 
> Which applications (games?) that you use have seemed to need this?

Re: [B2-devel] Thoughts on SheepShaver and Basilisk II

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

On Sat, Jun 16, 2012 at 2:42 PM, howard spoelstra <
how...@ho...> wrote:

>  Hi all,
>
> The sudden increase in activity on this ML makes for interesting reading.
> It looks like the development community is looking for an agenda? We, the
> maintainers of the http://www.emaculation.com website have ample
> experience in why and how SheepShaver is used by various groups of users.
> And have ample experience in what its shortcomings are. So, we would like
> to chime in from the user perspective.
>
> First of, something about importance: In the discussion these past days,
> someone suggested that SheepShaver is not all that important because much
> old software can be run in Mini vMac. This is certainly not true for those
> who use SheepShaver on an Intel Mac, by far the largest group of
> SheepShaver users. After the demise of the Classic environment and later
> Rosetta, SheepShaver is the only way left to run Mac OS applications on an
> emulated PowerPC processor. Many Mac users simply need SheepShaver to keep
> some old applications running or to have access to files in formats that
> are not supported by today's Mac software. SheepShaver became a necessary
> tool that, as we know from the forum discussions and support questions, in
> some cases is even used to run irreplaceable software that is vital to
> professionals, businesses, or scientists.
>
> Indeed. I was not saying that Mini vMac and DOSbox covered all or most of
the SheepShaver bases. I was merely saying that SheepShaver is not a
necessity for everybody's legacy application needs. A lot of software from
the nineties was also available on DOS and Windows and is much easier to
emulate that way. (We recently switched to the Windows version of a
particular application on our Macintoshes in order to allow for more
seamless integration via Wine.) On the Macintosh-only front, HyperCard has
tended to be, in my experience, the classic Macintosh thing that people
most want to emulate, and I have been able to recommend Mini vMac (and
sometimes RunRev) for that.

The classic Macintosh did not start with a large user base. When one
filters out people who are just enough satisfied with the OSX or Windows
equivalents of the classic applications, the people who can successfully
migrate to newer applications (like RunRev), and the people who just want
HyperCard, the pool of potential contributors, developers, and users is
relatively small.


> Someone called SheepShaver a niche product. While that in itself is true,
> we feel that some tender love and care (including some expansion in the
> feature set) could make it a bit less “nichy”. Looking around the Internet,
> one finds many failed attempts at getting SheepShaver running, or when it
> does run not providing the desired functionality.
>

Once again, I was not saying that SheepShaver was not important. It is very
important to several work-flows that I maintain. I was merely trying to
point out why emulation of a PowerPC Macintosh had not enjoyed the same
sort of attention that other projects such as DOS emulation have drawn. The
programming difficulties are much greater and the number of users much
smaller. If there were millions of people very interested in doing this,
there would be multiple projects and probably a commercial product or two.


> A point we would like to make is that we, as volunteer supporters/build
> providers, are not in favour of a diverging code base for the supported
> platforms.
>
> Towards a better feature set for all supported hosts:
> -Improved CD/DVD handling.
>
Like an eject key-stroke for disk images?


> -USB support.
> -Video acceleration on the host.
>

Which applications (games?) that you use have seemed to need this?


> -Memory management allowing running Mac OS above 9.0.4.
> -More opcodes supported, allowing more applications to work. (Office comes
> to mind).
>

I still use Word 5.1a on occasion without problems. Which version of Office
causes problems?

Also, are you sure that you aren't compiling with the PPC_REENTRANT_JIT
flag set to 1? That disables a number of operations that are supported.

-Improve networking, including Appletalk.
> -Improve communication to serial/parallel ports.
> -A possibility to launch a SheepShaver built-in preferences editor without
> the emulator starting (by holding a modifier key?). That would make a
> separate external preferences editor superfluous.
>

Wouldn't you prefer to have these separate? We actually disabled the
configuration editor in our environment. It is very rare that one wishes to
tweak a working configuration, and adding another step to start-up seems
unnecessary.


> -Improve SCSI support.
>
> As in allowing SheepShaver to interact with real SCSI devices? This would
be nice, certainly, but might produce some messy conflicts with host
operating system drivers if enabled by default.


> Specific for OSX:
> -Clipboard exchange for text in 64-bit mode SheepShaver (it currently
> doesn’t work at all in 64-bit mode.)
>
-Possibility to compile/build SheepShaver in MacOSX 10.7.x (Lion) and
> future versions.
>

That requires reworking lots of assembly that llvm dislikes. And I am not
sure what llvm likes.


> -Solution to the weird color problems on Intel Mac after SheepShaver
> window has been minimized or hidden and is brought back in view. (Possibly
> a SDL issue.)
>
> Specific for Windows:
> -Replace the reliance on the cdenable.sys cd rom driver for CD support. It
> currently doesn’t work on 64-bit hosts.
> -Replace the reliance on the BasiliskII Ethernet driver with for example
> WinPcap, as it currently doesn’t run on 64-bit hosts (requiring driver
> signing).
> -Replace reliance on Cygwin to build for Windows.
>

Would you prefer to get X11 from Windows Services for UNIX?


>
> Best regards,
> Ronald P. Regensburg and Howard Spoelstra
>
>
> ------------------------------------------------------------------------------
> 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] Reason for Git commit ceed8dca on github.com/tycho/sheepshaver

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

Oh, yes, I see now!

Yes, it looks like an optimization, aimed at a case where a block of
code is pre-decoded and then the PC jumps to a slightly earlier
address (and then, I'd assume, the whole thing gets purged, then later
the same thing happens again).

Perhaps "tycho" (Steven Noonan) has a program that is made faster by
this commit. It's been 2.5 years (2010 Dec 5) but maybe he remembers,
so I'm CC'ing him here.

On 6/16/12, Alexei Svitkine <ale...@gm...> wrote:
> PPC_DECODE_CACHE is enabled by default in the current CVS TOT.
>
> (The commit I linked too re-enabled it because that fork had disabled it at
> some point. My comments were about the other change that moved a few lines
> of code into a for loop.)
>
> On Sat, Jun 16, 2012 at 3:54 PM, Robert Munafo <mr...@gm...> wrote:
>
>> PPC_DECODE_CACHE enables a memory block decode_cache_p which holds up
>> to 32768 consecutive results of decode(opcode) for a block of
>> consecutive PPC instructions (32-bit words).
>>
>> There is a profiling function enabled by PPC_PROFILE_COMPILE_TIME
>> which will record the amount of CPU time used by the decode cache
>> function, printing "compile" vs "predecode" time vs total emulation
>> time.
>>
>> I'm also prone to wonder why PPC_DECODE_CACHE was disabled by default
>> -- it seems that if Gwenole went to all that effort implementing a
>> decode cache (it's about 150 lines of code), why would it be disabled
>> by default?
>>
>> On 6/16/12, Alexei Svitkine <ale...@gm...> wrote:
>> > For example, let's take this commit by Tycho which kallisti5 pulled:
>> >
>>
>> https://github.com/tycho/sheepshaver/commit/ceed8dca09fd5e5fe4e1bf9127d628382cb0f350
>> >
>> > Presumably this makes something faster. Maybe it does, it looks
>> plausible -
>> > [...]
>>

-- 
  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] git?

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

I would recommend this to anyone wanting to understand what Git actually does:

ftp.newartisans.com/pub/git.from.bottom.up.pdf
  "Git From the Bottom Up" by John Wiegley (PDF file), December 2009

He explains blobs, the index (aka "staging area"), working tree,
rebasing, etc. with lots of details like identifying a commit by an
unambiguous initial substring of its SHA1 hash.

There are a bunch of good illustrations showing the structure of the
repository and working tree databases.

Alex wrote:
> There are some examples of git usage and a flow chart I threw together a
> while back if anyone wants a *quick* crash course on GIT:
>
> https://www.haiku-os.org/guides/building/get-source-git
>
> Tips:
>    * Always git pull --rebase before you commit.
>      This will mimic a central repo better and avoid a mass amount of merges

-- 
  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] git?

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

Gee, well if the Windows solution involves a post-checkout script to
run a bunch of "mklink" commands, then we might as well *not* include
the symlinks in the repository, and retain the "make links" step that
we have now (but still move to Git or some other newer source code
management).

On 6/16/12, Alexei Svitkine <ale...@gm...> wrote:
> On Sat, Jun 16, 2012 at 1:16 PM, Alexei Svitkine wrote:
>
>> We could even have the symlinks checked in, so the separate script to
>> generate them won't be required.
>
> Looks like that wouldn't work well with Windows. Sigh:
>
> http://stackoverflow.com/questions/5917249/git-symlinks-in-windows

-- 
  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] git?

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

Also, Basilisk II's 680x0 emulation is waaaaaay faster than
SheepShaver running Apple's 68K emulation. Sometimes it's even faster
than a PowerPC version of the same program running on SheepShaver.

Here are some benchmarks for my Mandelbrot program, showing
floating-point performance of IEEE 32-bit and 64-bit floating-point
add/subtract/multiply. All are on the same 2.2 GHz Nehalem Core i7:

BasiliskII's JIT compiler running a 68K native version of the program:
  Single precision: 227 MFLOPs/sec
  Double precision: 55.2 MFLOPs/sec

SheepShaver running a PowerPC native version of the app:
  Single precision: 148 MFLOPs/sec
  Double precision: 164 MFLOPs/sec

SheepShaver's JIT compiler running Apple's 68K emulator, running the
68K version of the program and using SANE library for floating point:
  Single precision: 0.74 MFLOPs/sec
  Double precision: 0.69 MFLOPs/sec

>> I disagree with this one. Basilisk II is quite useful for running late
>> 68k Mac stuff, and it would be a shame for it not to pick up any improvements
>> that get made to the shared code.
>>
>> And Basilisk II seems to be a bit more flexible about the memory model .

-- 
  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] Thoughts on SheepShaver and Basilisk II

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

PPC_DECODE_CACHE is enabled by default in the current CVS TOT.

(The commit I linked too re-enabled it because that fork had disabled it at
some point. My comments were about the other change that moved a few lines
of code into a for loop.)

On Sat, Jun 16, 2012 at 3:54 PM, Robert Munafo <mr...@gm...> wrote:

> PPC_DECODE_CACHE enables a memory block decode_cache_p which holds up
> to 32768 consecutive results of decode(opcode) for a block of
> consecutive PPC instructions (32-bit words).
>
> There is a profiling function enabled by PPC_PROFILE_COMPILE_TIME
> which will record the amount of CPU time used by the decode cache
> function, printing "compile" vs "predecode" time vs total emulation
> time.
>
> I'm also prone to wonder why PPC_DECODE_CACHE was disabled by default
> -- it seems that if Gwenole went to all that effort implementing a
> decode cache (it's about 150 lines of code), why would it be disabled
> by default?
>
> On 6/16/12, Alexei Svitkine <ale...@gm...> wrote:
> > For example, let's take this commit by Tycho which kallisti5 pulled:
> >
>
> https://github.com/tycho/sheepshaver/commit/ceed8dca09fd5e5fe4e1bf9127d628382cb0f350
> >
> > Presumably this makes something faster. Maybe it does, it looks
> plausible -
> > [...]
>
> --
>  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] git?

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

Yes, we need Bas2, it's the only way to run System 6 and older System
7s, and they're the only way to run a lot of cool stuff (including
much that I wrote myself and have a fondness for :-)

On 6/16/12, Charles Srstka <bas...@ch...> wrote:
> On Jun 16, 2012, at 9:42 AM, Alexander von Gluck wrote:
> I disagree with this one. Basilisk II is quite useful for running late 68k
> Mac stuff, and it would be a shame for it not to pick up any improvements
> that get made to the shared code.

-- 
  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