basilisk-devel — Basilisk II development-related discussion

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

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

So as to avoid duplicative effort, can you share what areas you plan to
improve? If you do start working on re-implementing the memory management
layer, I would be willing to help.

On Fri, Jun 15, 2012 at 6:34 PM, Alexander von Gluck
<kal...@un...>wrote:

> On 15.06.2012 17:34, Lew Irwin/Studio Briefing wrote:
> > For us non-techies who are using SheepShaver with the old "fork," what
> > does this mean?
>
> Nothing really.  The GNU license means a fork can take place as long as
> some
> guidelines
> are followed:
>
>  * Copyrights can't be changed (eg, I can't go back and erase the names of
> all the people
>    who made SheepShaver possible)
>  * Trademark laws must be followed. (thus SheepShear vs SheepShaver)
>

And the resulting derivative products are forever locked into the G.P.L..
There are some down-sides to this, but it makes merging back changes from
those derivative products much simpler.


>
> Possible Pros:
>  * SheepShear adds all kinds of neat/crazy/hairbrain new features the
> SheepShaver developers
>    can use upstream if desired.
>  * SheepShear attracts more attention to Macintosh Classic emulation.
>  * If SheepShear dies... the SheepShaver devs have a potential pool of new
> features and changes
>  * If SheepShaver dies... SheepShear lives on.
>
> Possible Cons:
>  * SheepShear splits the community causing two weak projects vs one strong
> one (given the
>    decline in activity of SheepShaver I feel this risk is minimal)
>
>
> I've begin working on SheepShear, and SheepShaver will continue how it's
> founders see fit.
>
> Two code bases "forking" in two directions :)
>
>  -- Alex
>
>
> ------------------------------------------------------------------------------
> 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

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

On Fri, Jun 15, 2012 at 6:29 PM, Diskutant <dis...@go...> wrote:

> Well, that answer from Frank was quite nonsense (had nothing to do with
> your question)...
>

If you want to question my motives or intelligence, let's do that
off-thread. Personal attacks distract from the development and support
purposes of the list.

I assumed that Lew was concerned about the future of the project from the
perspective of having future-ready binaries available and responded
accordingly.


> It means nothing for now, it's just that there are some people working on
> it at some other place, what that means in the future, we will see.
>
>
>
> Am 16.06.2012 um 00:34 schrieb Lew Irwin/Studio Briefing:
>
> For us non-techies who are using SheepShaver with the old "fork," what
> does this mean?
>
> On Fri, Jun 15, 2012 at 3:21 PM, Alexei Svitkine <
> ale...@gm...> wrote:
>
>> Done.
>>>
>>> SheepShaver has a new fork called SheepShear.
>>>
>>> https://github.com/kallisti5/sheepshear
>>>
>>>
>>> Feel free to utilize any patches in sheepshear into the sheepshaver code.
>>>
>>
>> Cool! Looking forward to upstreaming your changes.
>>
>> I'm going to discontinue this discussion on
>>> bas...@li... as it is no longer relevant to
>>> SheepShaver or Basilisk II.
>>>
>>
>> Where will you be having the new discussion?
>>
>> -Alexei
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> --
> Lew Irwin
> STUDIO BRIEFING
> www.studiobriefing.net
> st...@us...
> (818) 865-0044
>
>
>
> ------------------------------------------------------------------------------
> 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] Thoughts on SheepShaver and Basilisk II

[Lew Irwin/S. B. <st...@us...>]

I think that the decline in SheepShaver activity probably stems from the
fact that it has received such little notice from the Mac magazines and
news sites. Every time I have shown my SheepShaver installation to an Apple
Store "genius," they have expressed surprise -- and often delight -- that
such a thing exists. Hardly any of them had ever heard of it.

On Fri, Jun 15, 2012 at 4:34 PM, Alexander von Gluck
<kal...@un...>wrote:

> On 15.06.2012 17:34, Lew Irwin/Studio Briefing wrote:
> > For us non-techies who are using SheepShaver with the old "fork," what
> > does this mean?
>
> Nothing really.  The GNU license means a fork can take place as long as
> some
> guidelines
> are followed:
>
>  * Copyrights can't be changed (eg, I can't go back and erase the names of
> all the people
>    who made SheepShaver possible)
>  * Trademark laws must be followed. (thus SheepShear vs SheepShaver)
>
> Possible Pros:
>  * SheepShear adds all kinds of neat/crazy/hairbrain new features the
> SheepShaver developers
>    can use upstream if desired.
>  * SheepShear attracts more attention to Macintosh Classic emulation.
>  * If SheepShear dies... the SheepShaver devs have a potential pool of new
> features and changes
>  * If SheepShaver dies... SheepShear lives on.
>
> Possible Cons:
>  * SheepShear splits the community causing two weak projects vs one strong
> one (given the
>    decline in activity of SheepShaver I feel this risk is minimal)
>
>
> I've begin working on SheepShear, and SheepShaver will continue how it's
> founders see fit.
>
> Two code bases "forking" in two directions :)
>
>  -- Alex
>
>
> ------------------------------------------------------------------------------
> 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
>



-- 
Lew Irwin
STUDIO BRIEFING
www.studiobriefing.net
st...@us...
(818) 865-0044

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

[Alexander v. G. <kal...@un...>]

On 15.06.2012 17:34, Lew Irwin/Studio Briefing wrote:
> For us non-techies who are using SheepShaver with the old "fork," what 
> does this mean?

Nothing really.  The GNU license means a fork can take place as long as some 
guidelines
are followed:

  * Copyrights can't be changed (eg, I can't go back and erase the names of 
all the people
    who made SheepShaver possible)
  * Trademark laws must be followed. (thus SheepShear vs SheepShaver)

Possible Pros:
  * SheepShear adds all kinds of neat/crazy/hairbrain new features the 
SheepShaver developers
    can use upstream if desired.
  * SheepShear attracts more attention to Macintosh Classic emulation.
  * If SheepShear dies... the SheepShaver devs have a potential pool of new 
features and changes
  * If SheepShaver dies... SheepShear lives on.

Possible Cons:
  * SheepShear splits the community causing two weak projects vs one strong 
one (given the
    decline in activity of SheepShaver I feel this risk is minimal)


I've begin working on SheepShear, and SheepShaver will continue how it's 
founders see fit.

Two code bases "forking" in two directions :)

  -- Alex

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

[Kevin J. (at home) <kj...@gm...>]

I don't know what the definition of 'many people' is, but I'm one. I need an old task manager called InControl, and an old version of 4D. And I feel a lot better about my old disks and files, dating back to 1988, knowing that I can read them with Sheepshaver if necessary. Shoot, I may just want to play some old games. Perhaps you could multiply the supposed scarcity of people like me, by the intensity with which we need Sheepshaver.

On Jun. 15, 2012, at 17:09 , Charles Srstka wrote:

> On Jun 15, 2012, at 5:40 PM, Frank Trampe wrote:
> 
>> Indeed, but the fact remains that not many people need the unique SheepShaver functionality.
> 
> Given that “the unique SheepShaver functionality” currently covers pretty much everything from the entire decade of the 90s, I’d have to disagree with you there.
> 
>> Last time I fiddled with Mini vMac, I was able to get Macintosh IIx stuff but not color working, I think. Let me check on that.
> 
> I’ve been able to get the OS booted, and color works. Unfortunately, most old software that I try to run ends up crashing the system with an “Unimplemented trap” error box, so it’s not too useful yet. This isn’t any surprise, as the author’s website plainly states that the Mac II support isn’t completely implemented yet, which is consistent with the error messages that I get. Given the extremely high quality of Mini vMac in general, I’m sure that once the Mac II support is finished, it’ll take over the top position for the area it will cover, but you’ll still need Basilisk/SheepShaver to run anything that needs a 68030 or higher.
> 
> 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

--
Sincerely, Kevin Jaques (at home)

Use ja...@hi... for work related messages

"Send lawyers, guns and money! Dad get me out of this!" - Warren Zevon

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

[Diskutant <dis...@go...>]

Well, that answer from Frank was quite nonsense (had nothing to do with your question)...
It means nothing for now, it's just that there are some people working on it at some other place, what that means in the future, we will see.



Am 16.06.2012 um 00:34 schrieb Lew Irwin/Studio Briefing:

> For us non-techies who are using SheepShaver with the old "fork," what does this mean?
> 
> On Fri, Jun 15, 2012 at 3:21 PM, Alexei Svitkine <ale...@gm...> wrote:
> Done.
> 
> SheepShaver has a new fork called SheepShear.
> 
> https://github.com/kallisti5/sheepshear
> 
> 
> Feel free to utilize any patches in sheepshear into the sheepshaver code.
> 
> Cool! Looking forward to upstreaming your changes.
> 
> I'm going to discontinue this discussion on
> bas...@li... as it is no longer relevant to
> SheepShaver or Basilisk II.
> 
> Where will you be having the new discussion?
>  
> -Alexei
> 
> ------------------------------------------------------------------------------
> 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
> 
> 
> 
> 
> -- 
> Lew Irwin
> STUDIO BRIEFING
> www.studiobriefing.net
> st...@us...
> (818) 865-0044
> 
> 
> ------------------------------------------------------------------------------
> 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

[Lew Irwin/S. B. <st...@us...>]

I use Macintoshes, and I've been using SheepShaver every day for many years
-- primarily so that I don't have to rebuild (in OS X) some macros with
hundreds of steps that employ Clarisworks, TexEdit, and Outlook Express. 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. (There are also a few other annoying glitches. For
example, I can't copy and paste in Clarisworks if Spell Catcher is turned
on.) And there have been several times when Sheepshaver simply crashes
(with the question mark icon appearing on start-up) and I have to replace
it with a back-up copy, losing my previous work in the process. So what
will the "fork" do for me -- if anything?

On Fri, Jun 15, 2012 at 3:53 PM, Frank Trampe <fra...@gm...>wrote:

> What platform are you using? If you have a set-up that works, it ought to
> continue to do so.
>
> For the environment that I maintain (which has Macintoshes), I built a
> self-contained folder with native x86 code on Snow Leopard with the
> expectation of using that for a long time. As I mentioned before, you can
> get this here (
> http://www.4shared.com/file/WZkaMsut/SheepShaver-23-Chicago-2012061.html
>  ).
>
> If you are running on Windows, you have binary compatibility into the
> distant future, so there is not much to do in order to keep things working.
>
> If you are running Linux, even static binaries are not particularly
> portable, but I have had good luck compiling across multiple Ubuntu
> versions once I made the necessary tweaks. In fact, I think that, as of
> early this year, the cvs source compiled for me with no changes, and I just
> needed to remove the configuration editor and to remove a few memory leaks.
> I put the source bundle that I use here (
> http://www.4shared.com/file/rDBPolED/Source_Day_20120316_3tar.html ).
>
> On Fri, Jun 15, 2012 at 5:34 PM, Lew Irwin/Studio Briefing <st...@us...
> > wrote:
>
>> For us non-techies who are using SheepShaver with the old "fork," what
>> does this mean?
>>
>> On Fri, Jun 15, 2012 at 3:21 PM, Alexei Svitkine <
>> ale...@gm...> wrote:
>>
>>> Done.
>>>>
>>>> SheepShaver has a new fork called SheepShear.
>>>>
>>>> https://github.com/kallisti5/sheepshear
>>>>
>>>>
>>>> Feel free to utilize any patches in sheepshear into the sheepshaver
>>>> code.
>>>>
>>>
>>> Cool! Looking forward to upstreaming your changes.
>>>
>>> I'm going to discontinue this discussion on
>>>> bas...@li... as it is no longer relevant to
>>>> SheepShaver or Basilisk II.
>>>>
>>>
>>> Where will you be having the new discussion?
>>>
>>> -Alexei
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>> --
>> Lew Irwin
>> STUDIO BRIEFING
>> www.studiobriefing.net
>> st...@us...
>> (818) 865-0044
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>


-- 
Lew Irwin
STUDIO BRIEFING
www.studiobriefing.net
st...@us...
(818) 865-0044

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

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

On Jun 15, 2012, at 5:40 PM, Frank Trampe wrote:

> Indeed, but the fact remains that not many people need the unique SheepShaver functionality.

Given that “the unique SheepShaver functionality” currently covers pretty much everything from the entire decade of the 90s, I’d have to disagree with you there.

> Last time I fiddled with Mini vMac, I was able to get Macintosh IIx stuff but not color working, I think. Let me check on that.

I’ve been able to get the OS booted, and color works. Unfortunately, most old software that I try to run ends up crashing the system with an “Unimplemented trap” error box, so it’s not too useful yet. This isn’t any surprise, as the author’s website plainly states that the Mac II support isn’t completely implemented yet, which is consistent with the error messages that I get. Given the extremely high quality of Mini vMac in general, I’m sure that once the Mac II support is finished, it’ll take over the top position for the area it will cover, but you’ll still need Basilisk/SheepShaver to run anything that needs a 68030 or higher.

Charles

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

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

I forgot to mention that the SheepShaver Assistant requires CocoaDialog to
be installed. But the SheepShaver binary and associated libraries ought to
work without it.

In order to install, extract the archive into /Applications, copy your
classic drive image over the blank disk image in the support folder,
install CocoaDialog, and run the Assistant. It automatically builds a
SheepShaver profile for you and launches SheepShaver.

On Fri, Jun 15, 2012 at 5:53 PM, Frank Trampe <fra...@gm...>wrote:

> What platform are you using? If you have a set-up that works, it ought to
> continue to do so.
>
> For the environment that I maintain (which has Macintoshes), I built a
> self-contained folder with native x86 code on Snow Leopard with the
> expectation of using that for a long time. As I mentioned before, you can
> get this here (
> http://www.4shared.com/file/WZkaMsut/SheepShaver-23-Chicago-2012061.html
>  ).
>
> If you are running on Windows, you have binary compatibility into the
> distant future, so there is not much to do in order to keep things working.
>
> If you are running Linux, even static binaries are not particularly
> portable, but I have had good luck compiling across multiple Ubuntu
> versions once I made the necessary tweaks. In fact, I think that, as of
> early this year, the cvs source compiled for me with no changes, and I just
> needed to remove the configuration editor and to remove a few memory leaks.
> I put the source bundle that I use here (
> http://www.4shared.com/file/rDBPolED/Source_Day_20120316_3tar.html ).
>
> On Fri, Jun 15, 2012 at 5:34 PM, Lew Irwin/Studio Briefing <st...@us...
> > wrote:
>
>> For us non-techies who are using SheepShaver with the old "fork," what
>> does this mean?
>>
>> On Fri, Jun 15, 2012 at 3:21 PM, Alexei Svitkine <
>> ale...@gm...> wrote:
>>
>>> Done.
>>>>
>>>> SheepShaver has a new fork called SheepShear.
>>>>
>>>> https://github.com/kallisti5/sheepshear
>>>>
>>>>
>>>> Feel free to utilize any patches in sheepshear into the sheepshaver
>>>> code.
>>>>
>>>
>>> Cool! Looking forward to upstreaming your changes.
>>>
>>> I'm going to discontinue this discussion on
>>>> bas...@li... as it is no longer relevant to
>>>> SheepShaver or Basilisk II.
>>>>
>>>
>>> Where will you be having the new discussion?
>>>
>>> -Alexei
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>> --
>> Lew Irwin
>> STUDIO BRIEFING
>> www.studiobriefing.net
>> st...@us...
>> (818) 865-0044
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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

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

What platform are you using? If you have a set-up that works, it ought to
continue to do so.

For the environment that I maintain (which has Macintoshes), I built a
self-contained folder with native x86 code on Snow Leopard with the
expectation of using that for a long time. As I mentioned before, you can
get this here (
http://www.4shared.com/file/WZkaMsut/SheepShaver-23-Chicago-2012061.html ).

If you are running on Windows, you have binary compatibility into the
distant future, so there is not much to do in order to keep things working.

If you are running Linux, even static binaries are not particularly
portable, but I have had good luck compiling across multiple Ubuntu
versions once I made the necessary tweaks. In fact, I think that, as of
early this year, the cvs source compiled for me with no changes, and I just
needed to remove the configuration editor and to remove a few memory leaks.
I put the source bundle that I use here (
http://www.4shared.com/file/rDBPolED/Source_Day_20120316_3tar.html ).

On Fri, Jun 15, 2012 at 5:34 PM, Lew Irwin/Studio Briefing
<st...@us...>wrote:

> For us non-techies who are using SheepShaver with the old "fork," what
> does this mean?
>
> On Fri, Jun 15, 2012 at 3:21 PM, Alexei Svitkine <
> ale...@gm...> wrote:
>
>> Done.
>>>
>>> SheepShaver has a new fork called SheepShear.
>>>
>>> https://github.com/kallisti5/sheepshear
>>>
>>>
>>> Feel free to utilize any patches in sheepshear into the sheepshaver code.
>>>
>>
>> Cool! Looking forward to upstreaming your changes.
>>
>> I'm going to discontinue this discussion on
>>> bas...@li... as it is no longer relevant to
>>> SheepShaver or Basilisk II.
>>>
>>
>> Where will you be having the new discussion?
>>
>> -Alexei
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> --
> Lew Irwin
> STUDIO BRIEFING
> www.studiobriefing.net
> st...@us...
> (818) 865-0044
>
>
>
>
> ------------------------------------------------------------------------------
> 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

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

On Fri, Jun 15, 2012 at 1:15 PM, Charles Srstka <
bas...@ch...> wrote:

> On Jun 15, 2012, at 1:03 PM, Frank Trampe wrote:
>
> SheepShaver is not a consumer tool for several reasons.
>
> One is that there are already good products for most of what it does. Most
> people can find Windows or 68K versions of the games or applications that
> they need, so SheepShaver is not necessary for them. Other applications run
> nicely in the classic environment for O.S. X, so one can put 10.4 in a
> PearPC wrapper and run the stuff there.
>
>
> Well, that’s not really true. The only other major Mac emulator is Mini
> vMac, and while it’s extremely good, it's mostly limited to very old
> applications from the 80s for the original black-and-white hardware. The
> support for Mac II, and color in general, was still quite unfinished the
> last time I looked at it, and there’s no support for the 68030 or 68040 at
> all. For a lot of early 90s Mac stuff, the only emulator that has a serious
> chance of working as it stands is Basilisk II/SheepShaver.
>
> Indeed, but the fact remains that not many people need the unique
SheepShaver functionality.

Last time I fiddled with Mini vMac, I was able to get Macintosh IIx stuff
but not color working, I think. Let me check on that.


> The other thing is that, as I understand it, the classic environment does
> not run in PearPC, so wrapping it in such a manner wouldn’t work.
>
> Sorry about that. I have always needed to keep a working SheepShaver
installation, so I have not had cause to try PearPC. I had assumed that
this was possible with the correct ROM file, but apparently not.


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

[Lew Irwin/S. B. <st...@us...>]

For us non-techies who are using SheepShaver with the old "fork," what does
this mean?

On Fri, Jun 15, 2012 at 3:21 PM, Alexei Svitkine
<ale...@gm...>wrote:

> Done.
>>
>> SheepShaver has a new fork called SheepShear.
>>
>> https://github.com/kallisti5/sheepshear
>>
>>
>> Feel free to utilize any patches in sheepshear into the sheepshaver code.
>>
>
> Cool! Looking forward to upstreaming your changes.
>
> I'm going to discontinue this discussion on
>> bas...@li... as it is no longer relevant to
>> SheepShaver or Basilisk II.
>>
>
> Where will you be having the new discussion?
>
> -Alexei
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 
Lew Irwin
STUDIO BRIEFING
www.studiobriefing.net
st...@us...
(818) 865-0044

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

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

>
> Done.
>
> SheepShaver has a new fork called SheepShear.
>
> https://github.com/kallisti5/sheepshear
>
>
> Feel free to utilize any patches in sheepshear into the sheepshaver code.
>

Cool! Looking forward to upstreaming your changes.

I'm going to discontinue this discussion on
> bas...@li... as it is no longer relevant to
> SheepShaver or Basilisk II.
>

Where will you be having the new discussion?

-Alexei

Re: [B2-devel] BasiliskII compilation issues

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

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.

-Alexei

On Fri, Jun 15, 2012 at 5:46 PM, Alexei Svitkine
<ale...@gm...>wrote:

> Does it work if you replace "mysig_t" with "sig_t" and "mysignal" with
> "signal"?
>
>
> On Fri, Jun 15, 2012 at 12:54 PM, Giulio Paci <giu...@gm...>wrote:
>
>> On 12/06/2012 02:01, Robert Munafo wrote:
>> > Hello Giulio,
>> >
>> > On 6/11/12, Giulio Paci <giu...@gm...> wrote:
>> >> On 10/06/2012 06:59, Robert Munafo wrote:
>> >>> You might have noticed that mysignal is part of a small C program used
>> >>> as a test during the autoconf process.  [...]
>> >>
>> >> Actually I did not notice it. How is it related mysignal being part of
>> a
>> >> test in configure and the error I am seeing?
>> >
>> > They both use the same name. This means that they might have both been
>> > put in by the same programmer. If there is a history of old versions
>> > of BasiliskII source code, then we could find out when the mysignal
>> > got added to autoconf, and perhaps that will give a clue as to who
>> > added it and maybe the other mysignal was added at the same time.
>>
>> In autoconf files they were there since the first CVS commit, but I do
>> not know how this can help.
>>
>> >>> What happens if you disable the "#define HAVE_DEV_PTMX 1" as Andreas
>> >>> Wiese suggested?
>> >>
>> >> I am in the same situation as Andreas: if I
>> >> 1) undefine HAVE_DEV_PTMX and
>> >> 2) include signal.h
>> >> I can complete the compilation. (Although I am not able to test the
>> >> resulting binary at the moment, because on the virtual machine I set up
>> >> for testing, the X server is not able to start).
>> >>
>> >> My goal is to have the compilation working without manual intervention
>> >> on as many Debian supported architectures as possible, so: I can accept
>> >> the point 2 above (as it is working in the general case), but I cannot
>> >> accept the point 1 (because I do not understand what I am tweaking and
>> >> why. Moreover the change is probably affecting other architectures).
>> >
>> > I suggest that you add the change in the same way that one normally
>> > makes such changes in Debian.
>> >
>> > This is probably done with the config files. Note that "HAVE_DEV_PTMX"
>> > appears in:
>> >
>> >   Unix/config.h.in
>> >   Unix/configure
>> >   Unix/configure.ac
>>
>> Yes, the two usual fixes are either 1) temporary patch the building
>> system or 2) wait for an upstream patched release.
>>
>> > I do not know how these files work, but I do remember that one or more
>> > of them is created based on one of the others, and I'm pretty sure
>> > this happens in the "autogen.sh" or "configure" step of the build
>> > process.
>>
>> config.h.in is normally generated by autoheader, configure.ac is usually
>> the manually edited main source and configure is automatically generated
>> by autoconf and is responsible to convert .in files into the final file
>> (e.g., to create config.h from config.h.in).
>>
>> > Whichever one is the "original" configure file, needs to be edited so
>> > that it tests for Debian and disables the define of HAVE_DEV_PTMX if
>> > the Debian test is true.
>>
>> The problem is that 1) I do not understand what to check for and 2) I do
>> not understand the implication of undefining HAVE_DEV_PTMX.
>>
>> It is not a matter to detect Debian, as the building procedure is
>> already working on many Debian architectures. It is a matter of
>> detecting freebsd kernel in a Debian OS, but why? What features is
>> missing? As the same problem appeared long time ago in NetBSD and other
>> *BSD, is it related to FreeBSD?
>>
>> > Once you determine the best way to change the right config file, then
>> > report the details back to this list. There are people on this list
>> > who can update the source code server to reflect the bug fix, once
>> > they are told what needs to be changed.
>>
>> Once I will determine it I will do it for sure, but I do not think I
>> have the knowledge to determine it on my own.
>>
>> Bests,
>>        Giulio.
>>
>>
>> ------------------------------------------------------------------------------
>> 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

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

Does it work if you replace "mysig_t" with "sig_t" and "mysignal" with
"signal"?

On Fri, Jun 15, 2012 at 12:54 PM, Giulio Paci <giu...@gm...> wrote:

> On 12/06/2012 02:01, Robert Munafo wrote:
> > Hello Giulio,
> >
> > On 6/11/12, Giulio Paci <giu...@gm...> wrote:
> >> On 10/06/2012 06:59, Robert Munafo wrote:
> >>> You might have noticed that mysignal is part of a small C program used
> >>> as a test during the autoconf process.  [...]
> >>
> >> Actually I did not notice it. How is it related mysignal being part of a
> >> test in configure and the error I am seeing?
> >
> > They both use the same name. This means that they might have both been
> > put in by the same programmer. If there is a history of old versions
> > of BasiliskII source code, then we could find out when the mysignal
> > got added to autoconf, and perhaps that will give a clue as to who
> > added it and maybe the other mysignal was added at the same time.
>
> In autoconf files they were there since the first CVS commit, but I do
> not know how this can help.
>
> >>> What happens if you disable the "#define HAVE_DEV_PTMX 1" as Andreas
> >>> Wiese suggested?
> >>
> >> I am in the same situation as Andreas: if I
> >> 1) undefine HAVE_DEV_PTMX and
> >> 2) include signal.h
> >> I can complete the compilation. (Although I am not able to test the
> >> resulting binary at the moment, because on the virtual machine I set up
> >> for testing, the X server is not able to start).
> >>
> >> My goal is to have the compilation working without manual intervention
> >> on as many Debian supported architectures as possible, so: I can accept
> >> the point 2 above (as it is working in the general case), but I cannot
> >> accept the point 1 (because I do not understand what I am tweaking and
> >> why. Moreover the change is probably affecting other architectures).
> >
> > I suggest that you add the change in the same way that one normally
> > makes such changes in Debian.
> >
> > This is probably done with the config files. Note that "HAVE_DEV_PTMX"
> > appears in:
> >
> >   Unix/config.h.in
> >   Unix/configure
> >   Unix/configure.ac
>
> Yes, the two usual fixes are either 1) temporary patch the building
> system or 2) wait for an upstream patched release.
>
> > I do not know how these files work, but I do remember that one or more
> > of them is created based on one of the others, and I'm pretty sure
> > this happens in the "autogen.sh" or "configure" step of the build
> > process.
>
> config.h.in is normally generated by autoheader, configure.ac is usually
> the manually edited main source and configure is automatically generated
> by autoconf and is responsible to convert .in files into the final file
> (e.g., to create config.h from config.h.in).
>
> > Whichever one is the "original" configure file, needs to be edited so
> > that it tests for Debian and disables the define of HAVE_DEV_PTMX if
> > the Debian test is true.
>
> The problem is that 1) I do not understand what to check for and 2) I do
> not understand the implication of undefining HAVE_DEV_PTMX.
>
> It is not a matter to detect Debian, as the building procedure is
> already working on many Debian architectures. It is a matter of
> detecting freebsd kernel in a Debian OS, but why? What features is
> missing? As the same problem appeared long time ago in NetBSD and other
> *BSD, is it related to FreeBSD?
>
> > Once you determine the best way to change the right config file, then
> > report the details back to this list. There are people on this list
> > who can update the source code server to reflect the bug fix, once
> > they are told what needs to be changed.
>
> Once I will determine it I will do it for sure, but I do not think I
> have the knowledge to determine it on my own.
>
> Bests,
>        Giulio.
>
>
> ------------------------------------------------------------------------------
> 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

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

On Jun 15, 2012, at 1:03 PM, Frank Trampe wrote:

> SheepShaver is not a consumer tool for several reasons.
> 
> One is that there are already good products for most of what it does. Most people can find Windows or 68K versions of the games or applications that they need, so SheepShaver is not necessary for them. Other applications run nicely in the classic environment for O.S. X, so one can put 10.4 in a PearPC wrapper and run the stuff there.

Well, that’s not really true. The only other major Mac emulator is Mini vMac, and while it’s extremely good, it's mostly limited to very old applications from the 80s for the original black-and-white hardware. The support for Mac II, and color in general, was still quite unfinished the last time I looked at it, and there’s no support for the 68030 or 68040 at all. For a lot of early 90s Mac stuff, the only emulator that has a serious chance of working as it stands is Basilisk II/SheepShaver.

The other thing is that, as I understand it, the classic environment does not run in PearPC, so wrapping it in such a manner wouldn’t work.

Charles

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

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

On Fri, Jun 15, 2012 at 11:13 AM, Diskutant <dis...@go...>wrote:

> I'm 100% with Alexander!
>
> It's so much easier to use GitHub, I fork projects with a simple click, do
> changes, those are public for everyone and if I think I finished something
> good I ask the main repo to just pull my changes. I love it!
> Just because I know how to use CVS doesn't mean I want to. Besides, one
> would need write access.
> I created a repo on GitHub already, I'm just not happy with the way I did,
> so I might delete it, create a repo for SS and Basilisk and then work my
> way on moving everything needed from the Basilisk repo into the SS one.
> The problem then would be to stay up to date with the few changes that are
> still happening to CVS, I might just do that manually...
> Anyway, I'm highly interested in the project, I just don't want to use
> some stupid stuff like CVS anymore.
>
> And SS is everything but mature. There is so much stuff that need fixed.
> It crashed a lot, it needs updates to be more user friendly, more
> compatible, more everything.
>

These problems tend to result from large structural problems or design
decisions (the memory management system and the choice to intercept
specific Mac O.S. functionality rather than emulating the hardware) rather
than from small bugs. The problems have never been sufficient, at least for
me, to justify rewriting everything as would be necessary to correct those
problems.


> The GUI of SS sucks hard, well, that little that is there, it needs more
> GUI, and yes it's easier to just change the config file, that's because the
> GUI sucks!
>

I made an automatic configuration tool for Mac O.S. that creates a user
profile and makes a copy of the system disk image. I can upload it
somewhere if you like.

If you want to make a new configuration editor, I would suggest starting
from the beginning with a tool that reads and writes configuration files.
GLIDE might be nice for this.


> I understand that some ppl just like to do configs in a file with vi but a
> normal user doesn't. There would be more users if it were much easier to
> use, and much more compatible. Many users just want to play some old games.
> Check Boxer, it did something really great out of just a DOS Box. No one
> really wants the pain which comes with DOS Box, but Boxer hides all that
> and has a good fanbase because it's easy to use and it looks great. It's a
> Mac thing afterall.
>
> DOSBox is a consumer tool. I think that most people use it for playing
games. (I tried to get AutoCAD R13 working once, but that did not go well.)
I am satisfied with its configuration options, but I understand that a
large portion of its target user base would benefit from additional
support. If you want something like DOSBox, use Mini vMacs.

SheepShaver is not a consumer tool for several reasons.

One is that there are already good products for most of what it does. Most
people can find Windows or 68K versions of the games or applications that
they need, so SheepShaver is not necessary for them. Other applications run
nicely in the classic environment for O.S. X, so one can put 10.4 in a
PearPC wrapper and run the stuff there.

SheepShaver is written as a wrapper for classic versions of Mac O.S. rather
than as a machine emulator. This has performance benefits, but it also
means that the unstable operating system can and does crash SheepShaver
quite often. In my experience, SheepShaver is about as stable as a System 7
Macintosh. One could add checks so as to keep the operating system from
crashing the emulator, but that doesn't stop the operating system from
crashing itself.

SheepShaver is also at a disadvantage in terms of bundling. Due to the
legal issues involving the ROMs and the operating system, it is impossible
to offer SheepShaver as a ready-to-go tool like DOSBox. Likewise, its
complexity creates a bit of a library mess, so distributing even just the
executable is much more complicated than for something like Mini vMacs.
Likewise, the complicated in-line assembly code breaks compilation on
clang-llvm, which is a problem since that is what Apple ships as of Lion.

In the interest of improving distributability, I made a bundle for Mac O.S.
that includes the required libraries and such as well as the previously
mentioned profile assistant. It ought to run on Macintoshes for the
forseeable future. I uploaded it to 4Shared (
http://www.4shared.com/file/WZkaMsut/SheepShaver-23-Chicago-2012061.html ).
Just untar it, put it in /Applications, replace the blank
Classic_Drive_1.img file with your classic drive, and go. I also fixed some
memory leaks in this version, in part by disabling the configuration
editor. I will try to find the source code in the near future.


> Alex, I would say just import the CVS code into GitHub or where ever you
> like, let us know and we just might move over. :-)
>
> Thanks.
>
>
> Am 15.06.2012 um 17:48 schrieb Frank Trampe:
>
>
>
> On Fri, Jun 15, 2012 at 10:17 AM, Alexander von Gluck <
> kal...@un...> wrote:
>
>> On 15.06.2012 09:45, Frank Trampe wrote:
>> > On Fri, Jun 15, 2012 at 8:43 AM, Alexander von Gluck
>> > <kal...@un... [4]> wrote:
>> >
>> >> Good morning,
>> >>
>> >> I've been a off and on user of SheepShaver and Basilisk II for *years*
>> >> (and
>> >> years, and years). It offers decent
>> >> emulation and is the best emulator out there for classic MacOS.
>> >>
>> >> Over the last 5+ years... not a lot has changed. Here is my take on
>> some
>> >> of
>> >> the current limitations of the project:
>> >>
>> >>  * CVS
>> >>    Most projects left cvs for other version control software years ago.
>> >> Much
>> >> better source revision control software
>> >>    exist. If there aren't many developers out there who know how to use
>> >> the
>> >> revision tracking software for a project...
>> >>    no one will know how to (or want) to contribute.
>> >
>> > The instructions on the download page work quite well. They may have
>> been
>> > updated since you last checked (although at
>> > least five years ago).
>> >
>> > cvs is not any more difficult to use than other revision control
>> systems.
>> > It lacks some of the features of svn and
>> > git, but those are not necessary for a project with so few contributors
>> > and so few commits.
>>
>> This seems like a self-fulfilling prophecy. Why do we have so few commits
>> and interest? why should we move away from
>> a 21-year old overly complex version control software that no one uses
>> anymore?
>>
>> I do not think that the lack of commits to the project results from
> people turning their noses up at the revision control system. Those who are
> interested in the project do not make many commits because the product is
> mature. Those who are not interested in the project lack interest because
> they do not need such a product as SheepShaver. SheepShaver is a bit of a
> niche product since Mini vMacs works so well for those who do not need
> PowerPC emulation.
>
>
>> > The project does not need contributors who cannot figure out how to use
>> > cvs. It does not lack for features. It just
>> > needs some work on the memory access stuff, which is the sort of thing
>> > that is so complicated that only somebody who
>> > has already been a long-time contributor to the project could do it.
>>
>> Open source development is an evolving ecosystem, a healthy project has
>> users come and go improving parts they find
>> interesting.
>>
>> Assuming someone wouldn't know how to write an MMU to perform physical to
>> virtual address translation based on the
>> fact that they don't know how to use a 21 year old version control system
>> which hasn't seen a major update in 6+ years
>> is a pretty strange assumption.
>>
>> I am not expecting somebody to have a prior background with cvs; I would
> rather be concerned about the technical abilities of somebody who can't
> figure out the three or four commands necessary to use it. Is this concern
> unreasonable?
>
>
>> >>  * Complexity
>> >>    I remember being an early user and struggling figuring out how to
>> >> compile
>> >> SheepShaver. Needing to check out
>> >>    two different source trees and have a script smash them together via
>> >> symlinks was pretty hard to figure out.
>> >
>> > This is quite simple now. You check out the two source trees in the same
>> > directory, change to the SheepShaver
>> > directory, run make links, and then build for your platform. I do not
>> need
>> > to make any changes in the Basilisk II
>> > tree
>> > as mentioned in the instructions. A top-level configure script might be
>> in
>> > order, but my configuration needs are
>> > simple enough that I have not been tempted to write one.
>> >
>> > With respect to solving the supposed problem of having separate source
>> > trees for the two products, what is your
>> > proposal? To eliminate SheepShaver's dependency upon the Basilisk II
>> > components? It seems best to me to continue to
>> > share the common code since, otherwise, changes would probably not
>> > propagate correctly to both trees.
>>
>> Right, however the tangled web of symlinks makes development on either
>> project difficult. Who would want to
>> clean up a repo that several other projects depend on static file
>> locations?
>>
>> I just ignore the symlinks and edit the files from the SheepShaver tree.
> There is certainly room for improvement in the directory structure, but I
> have not found this to be a great obstacle to development.
>
>
>> >
>> >> r>
>> >>
>> >> The SheepShaver project is not responsible for the design of Mac O.S.,
>> >> and Apple is not
>> > he classic versions anymore. If you do not like it, consider using a
>> > different operating system. (What do you think
>> > of
>> > Haiku?)
>>
>> The *SheepShaver* interface, not the MacOS classic UI.
>>
>> Are you talking about the configuration editor? It has memory leaks and
> other problems, and nobody seems to need it anyway, so I disable it
> whenever I compile SheepShaver. It is much easier to edit the configuration
> file.
>
>
>>
>> Given the responses above, and the complete lack of activity on the
>> mailing
>> list over the years... it seems like there
>> really isn't any interest in keeping the project alive as an evolving open
>> source application. (which may also explain
>> why there has been little interest over the years)
>>
>> The project is not dead. The issue is more that it does not require much
> evolution in order to suit people's needs. I needed to make some changes to
> an internal version of SheepShaver about a year ago in order to support
> compilation on 64-bit architectures, and Alexei made similar changes at
> about the same time to the active tree, but there simply aren't many things
> left to be done. We had a flurry of commits (all from Alexei) this past
> winter that fixed a number of problems.
>
> There are some big issues that everybody would like to see addressed, but
> they do not stop SheepShaver from working most of the time, and they are so
> difficult to solve that it is hard to justify spending time on them.
>
> The structural changes that you propose to the project would break a lot
> of compatibility with people's custom build and patching systems.  If you
> want to evolve the project as you describe, it might be best to check out
> the sources and then to start a new repository of your choice elsewhere
> after you complete the restructuring that you have in mind.
>
>
>> I'm trying to be helpful here and maybe help nudge things into a more
>> active
>> position. (I wouldn't be making these
>> emails if I wasn't interested in putting some work into the project)
>>
>> What deficiencies in the product caused you to become interested in
> helping with the development? If your complaint is not about the memory
> management, it might be easily fixable. In fact, judging from my
> experience, if you put a few hours into trying to correct the problem,
> Alexei will commit a fix for the problem before you finish yours. This has
> happened for me about four times.
>
> What host operating system are you using, by the way?
>
>
>>  -- Alex
>>
>>
>> ------------------------------------------------------------------------------
>> 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] Thoughts on SheepShaver and Basilisk II

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

On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck <kal...@un...
> wrote:

> On 15.06.2012 11:13, Diskutant wrote:
> > I'm 100% with Alexander!
> >
> > It's so much easier to use GitHub, I fork projects with a simple click,
> do
> > changes, those are public for everyone and
> > if I think I finished something good I ask the main repo to just pull my
> > changes. I love it!
> > Just because I know how to use CVS doesn't mean I want to. Besides, one
> > would need write access.
> >
> > Alex, I would say just import the CVS code into GitHub or where ever you
> > like, let us know and we just might move
> > over. :-)
>
> Done.
>
> SheepShaver has a new fork called SheepShear.
>
> https://github.com/kallisti5/sheepshear
>
>
> Feel free to utilize any patches in sheepshear into the sheepshaver code.
>
> Right now i'm pouring over the other existing forks on Github of
> SheepShaver
> and cherrypicking patches not in the
> SheepShaver codebase (giving the other authors credit)
>
> I'm going to discontinue this discussion on
> bas...@li... as it is no longer relevant to
> SheepShaver
> or Basilisk II.
>
> I don't know about that. Since both projects seek to do the same things
using the same tools, I think that keeping a shared discussion of common
issues is the best way to advance both projects.


> Thanks for all the hard work over the years!
>
>  -- Alex
>
>
> ------------------------------------------------------------------------------
> 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

[Alexander v. G. <kal...@un...>]

On 15.06.2012 11:13, Diskutant wrote:
> I'm 100% with Alexander!
>
> It's so much easier to use GitHub, I fork projects with a simple click, do 
> changes, those are public for everyone and
> if I think I finished something good I ask the main repo to just pull my 
> changes. I love it!
> Just because I know how to use CVS doesn't mean I want to. Besides, one 
> would need write access.
>
> Alex, I would say just import the CVS code into GitHub or where ever you 
> like, let us know and we just might move
> over. :-)

Done.

SheepShaver has a new fork called SheepShear.

https://github.com/kallisti5/sheepshear


Feel free to utilize any patches in sheepshear into the sheepshaver code.

Right now i'm pouring over the other existing forks on Github of SheepShaver 
and cherrypicking patches not in the
SheepShaver codebase (giving the other authors credit)

I'm going to discontinue this discussion on 
bas...@li... as it is no longer relevant to 
SheepShaver
or Basilisk II.

Thanks for all the hard work over the years!

  -- Alex

Re: [B2-devel] BasiliskII compilation issues

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

On 12/06/2012 02:01, Robert Munafo wrote:
> Hello Giulio,
> 
> On 6/11/12, Giulio Paci <giu...@gm...> wrote:
>> On 10/06/2012 06:59, Robert Munafo wrote:
>>> You might have noticed that mysignal is part of a small C program used
>>> as a test during the autoconf process.  [...]
>>
>> Actually I did not notice it. How is it related mysignal being part of a
>> test in configure and the error I am seeing?
> 
> They both use the same name. This means that they might have both been
> put in by the same programmer. If there is a history of old versions
> of BasiliskII source code, then we could find out when the mysignal
> got added to autoconf, and perhaps that will give a clue as to who
> added it and maybe the other mysignal was added at the same time.

In autoconf files they were there since the first CVS commit, but I do
not know how this can help.

>>> What happens if you disable the "#define HAVE_DEV_PTMX 1" as Andreas
>>> Wiese suggested?
>>
>> I am in the same situation as Andreas: if I
>> 1) undefine HAVE_DEV_PTMX and
>> 2) include signal.h
>> I can complete the compilation. (Although I am not able to test the
>> resulting binary at the moment, because on the virtual machine I set up
>> for testing, the X server is not able to start).
>>
>> My goal is to have the compilation working without manual intervention
>> on as many Debian supported architectures as possible, so: I can accept
>> the point 2 above (as it is working in the general case), but I cannot
>> accept the point 1 (because I do not understand what I am tweaking and
>> why. Moreover the change is probably affecting other architectures).
> 
> I suggest that you add the change in the same way that one normally
> makes such changes in Debian.
> 
> This is probably done with the config files. Note that "HAVE_DEV_PTMX"
> appears in:
> 
>   Unix/config.h.in
>   Unix/configure
>   Unix/configure.ac

Yes, the two usual fixes are either 1) temporary patch the building
system or 2) wait for an upstream patched release.

> I do not know how these files work, but I do remember that one or more
> of them is created based on one of the others, and I'm pretty sure
> this happens in the "autogen.sh" or "configure" step of the build
> process.

config.h.in is normally generated by autoheader, configure.ac is usually
the manually edited main source and configure is automatically generated
by autoconf and is responsible to convert .in files into the final file
(e.g., to create config.h from config.h.in).

> Whichever one is the "original" configure file, needs to be edited so
> that it tests for Debian and disables the define of HAVE_DEV_PTMX if
> the Debian test is true.

The problem is that 1) I do not understand what to check for and 2) I do
not understand the implication of undefining HAVE_DEV_PTMX.

It is not a matter to detect Debian, as the building procedure is
already working on many Debian architectures. It is a matter of
detecting freebsd kernel in a Debian OS, but why? What features is
missing? As the same problem appeared long time ago in NetBSD and other
*BSD, is it related to FreeBSD?

> Once you determine the best way to change the right config file, then
> report the details back to this list. There are people on this list
> who can update the source code server to reflect the bug fix, once
> they are told what needs to be changed.

Once I will determine it I will do it for sure, but I do not think I
have the knowledge to determine it on my own.

Bests,
	Giulio.

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

[Diskutant <dis...@go...>]

I'm 100% with Alexander!

It's so much easier to use GitHub, I fork projects with a simple click, do changes, those are public for everyone and if I think I finished something good I ask the main repo to just pull my changes. I love it!
Just because I know how to use CVS doesn't mean I want to. Besides, one would need write access.
I created a repo on GitHub already, I'm just not happy with the way I did, so I might delete it, create a repo for SS and Basilisk and then work my way on moving everything needed from the Basilisk repo into the SS one.
The problem then would be to stay up to date with the few changes that are still happening to CVS, I might just do that manually...
Anyway, I'm highly interested in the project, I just don't want to use some stupid stuff like CVS anymore.

And SS is everything but mature. There is so much stuff that need fixed. It crashed a lot, it needs updates to be more user friendly, more compatible, more everything.
The GUI of SS sucks hard, well, that little that is there, it needs more GUI, and yes it's easier to just change the config file, that's because the GUI sucks!
I understand that some ppl just like to do configs in a file with vi but a normal user doesn't. There would be more users if it were much easier to use, and much more compatible. Many users just want to play some old games. Check Boxer, it did something really great out of just a DOS Box. No one really wants the pain which comes with DOS Box, but Boxer hides all that and has a good fanbase because it's easy to use and it looks great. It's a Mac thing afterall.

Alex, I would say just import the CVS code into GitHub or where ever you like, let us know and we just might move over. :-)

Thanks.


Am 15.06.2012 um 17:48 schrieb Frank Trampe:

> 
> 
> On Fri, Jun 15, 2012 at 10:17 AM, Alexander von Gluck <kal...@un...> wrote:
> On 15.06.2012 09:45, Frank Trampe wrote:
> > On Fri, Jun 15, 2012 at 8:43 AM, Alexander von Gluck
> > <kal...@un... [4]> wrote:
> >
> >> Good morning,
> >>
> >> I've been a off and on user of SheepShaver and Basilisk II for *years*
> >> (and
> >> years, and years). It offers decent
> >> emulation and is the best emulator out there for classic MacOS.
> >>
> >> Over the last 5+ years... not a lot has changed. Here is my take on some
> >> of
> >> the current limitations of the project:
> >>
> >>  * CVS
> >>    Most projects left cvs for other version control software years ago.
> >> Much
> >> better source revision control software
> >>    exist. If there aren't many developers out there who know how to use
> >> the
> >> revision tracking software for a project...
> >>    no one will know how to (or want) to contribute.
> >
> > The instructions on the download page work quite well. They may have been
> > updated since you last checked (although at
> > least five years ago).
> >
> > cvs is not any more difficult to use than other revision control systems.
> > It lacks some of the features of svn and
> > git, but those are not necessary for a project with so few contributors
> > and so few commits.
> 
> This seems like a self-fulfilling prophecy. Why do we have so few commits
> and interest? why should we move away from
> a 21-year old overly complex version control software that no one uses
> anymore?
> 
> I do not think that the lack of commits to the project results from people turning their noses up at the revision control system. Those who are interested in the project do not make many commits because the product is mature. Those who are not interested in the project lack interest because they do not need such a product as SheepShaver. SheepShaver is a bit of a niche product since Mini vMacs works so well for those who do not need PowerPC emulation.
>  
> > The project does not need contributors who cannot figure out how to use
> > cvs. It does not lack for features. It just
> > needs some work on the memory access stuff, which is the sort of thing
> > that is so complicated that only somebody who
> > has already been a long-time contributor to the project could do it.
> 
> Open source development is an evolving ecosystem, a healthy project has
> users come and go improving parts they find
> interesting.
> 
> Assuming someone wouldn't know how to write an MMU to perform physical to
> virtual address translation based on the
> fact that they don't know how to use a 21 year old version control system
> which hasn't seen a major update in 6+ years
> is a pretty strange assumption.
> 
> I am not expecting somebody to have a prior background with cvs; I would rather be concerned about the technical abilities of somebody who can't figure out the three or four commands necessary to use it. Is this concern unreasonable?
>  
> >>  * Complexity
> >>    I remember being an early user and struggling figuring out how to
> >> compile
> >> SheepShaver. Needing to check out
> >>    two different source trees and have a script smash them together via
> >> symlinks was pretty hard to figure out.
> >
> > This is quite simple now. You check out the two source trees in the same
> > directory, change to the SheepShaver
> > directory, run make links, and then build for your platform. I do not need
> > to make any changes in the Basilisk II
> > tree
> > as mentioned in the instructions. A top-level configure script might be in
> > order, but my configuration needs are
> > simple enough that I have not been tempted to write one.
> >
> > With respect to solving the supposed problem of having separate source
> > trees for the two products, what is your
> > proposal? To eliminate SheepShaver's dependency upon the Basilisk II
> > components? It seems best to me to continue to
> > share the common code since, otherwise, changes would probably not
> > propagate correctly to both trees.
> 
> Right, however the tangled web of symlinks makes development on either
> project difficult. Who would want to
> clean up a repo that several other projects depend on static file locations?
> 
> I just ignore the symlinks and edit the files from the SheepShaver tree. There is certainly room for improvement in the directory structure, but I have not found this to be a great obstacle to development.
>  
> >
> >> r>
> >>
> >> The SheepShaver project is not responsible for the design of Mac O.S.,
> >> and Apple is not
> > he classic versions anymore. If you do not like it, consider using a
> > different operating system. (What do you think
> > of
> > Haiku?)
> 
> The *SheepShaver* interface, not the MacOS classic UI.
> 
> Are you talking about the configuration editor? It has memory leaks and other problems, and nobody seems to need it anyway, so I disable it whenever I compile SheepShaver. It is much easier to edit the configuration file.
>  
> 
> Given the responses above, and the complete lack of activity on the mailing
> list over the years... it seems like there
> really isn't any interest in keeping the project alive as an evolving open
> source application. (which may also explain
> why there has been little interest over the years)
> 
> The project is not dead. The issue is more that it does not require much evolution in order to suit people's needs. I needed to make some changes to an internal version of SheepShaver about a year ago in order to support compilation on 64-bit architectures, and Alexei made similar changes at about the same time to the active tree, but there simply aren't many things left to be done. We had a flurry of commits (all from Alexei) this past winter that fixed a number of problems.
> 
> There are some big issues that everybody would like to see addressed, but they do not stop SheepShaver from working most of the time, and they are so difficult to solve that it is hard to justify spending time on them.
> 
> The structural changes that you propose to the project would break a lot of compatibility with people's custom build and patching systems.  If you want to evolve the project as you describe, it might be best to check out the sources and then to start a new repository of your choice elsewhere after you complete the restructuring that you have in mind.
>  
> I'm trying to be helpful here and maybe help nudge things into a more active
> position. (I wouldn't be making these
> emails if I wasn't interested in putting some work into the project)
> 
> What deficiencies in the product caused you to become interested in helping with the development? If your complaint is not about the memory management, it might be easily fixable. In fact, judging from my experience, if you put a few hours into trying to correct the problem, Alexei will commit a fix for the problem before you finish yours. This has happened for me about four times.
> 
> What host operating system are you using, by the way?
>  
>  -- Alex
> 
> ------------------------------------------------------------------------------
> 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] Thoughts on SheepShaver and Basilisk II

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

On Fri, Jun 15, 2012 at 10:17 AM, Alexander von Gluck <kal...@un...
> wrote:

> On 15.06.2012 09:45, Frank Trampe wrote:
> > On Fri, Jun 15, 2012 at 8:43 AM, Alexander von Gluck
> > <kal...@un... [4]> wrote:
> >
> >> Good morning,
> >>
> >> I've been a off and on user of SheepShaver and Basilisk II for *years*
> >> (and
> >> years, and years). It offers decent
> >> emulation and is the best emulator out there for classic MacOS.
> >>
> >> Over the last 5+ years... not a lot has changed. Here is my take on some
> >> of
> >> the current limitations of the project:
> >>
> >>  * CVS
> >>    Most projects left cvs for other version control software years ago.
> >> Much
> >> better source revision control software
> >>    exist. If there aren't many developers out there who know how to use
> >> the
> >> revision tracking software for a project...
> >>    no one will know how to (or want) to contribute.
> >
> > The instructions on the download page work quite well. They may have been
> > updated since you last checked (although at
> > least five years ago).
> >
> > cvs is not any more difficult to use than other revision control systems.
> > It lacks some of the features of svn and
> > git, but those are not necessary for a project with so few contributors
> > and so few commits.
>
> This seems like a self-fulfilling prophecy. Why do we have so few commits
> and interest? why should we move away from
> a 21-year old overly complex version control software that no one uses
> anymore?
>
> I do not think that the lack of commits to the project results from people
turning their noses up at the revision control system. Those who are
interested in the project do not make many commits because the product is
mature. Those who are not interested in the project lack interest because
they do not need such a product as SheepShaver. SheepShaver is a bit of a
niche product since Mini vMacs works so well for those who do not need
PowerPC emulation.


> > The project does not need contributors who cannot figure out how to use
> > cvs. It does not lack for features. It just
> > needs some work on the memory access stuff, which is the sort of thing
> > that is so complicated that only somebody who
> > has already been a long-time contributor to the project could do it.
>
> Open source development is an evolving ecosystem, a healthy project has
> users come and go improving parts they find
> interesting.
>
> Assuming someone wouldn't know how to write an MMU to perform physical to
> virtual address translation based on the
> fact that they don't know how to use a 21 year old version control system
> which hasn't seen a major update in 6+ years
> is a pretty strange assumption.
>
> I am not expecting somebody to have a prior background with cvs; I would
rather be concerned about the technical abilities of somebody who can't
figure out the three or four commands necessary to use it. Is this concern
unreasonable?


> >>  * Complexity
> >>    I remember being an early user and struggling figuring out how to
> >> compile
> >> SheepShaver. Needing to check out
> >>    two different source trees and have a script smash them together via
> >> symlinks was pretty hard to figure out.
> >
> > This is quite simple now. You check out the two source trees in the same
> > directory, change to the SheepShaver
> > directory, run make links, and then build for your platform. I do not
> need
> > to make any changes in the Basilisk II
> > tree
> > as mentioned in the instructions. A top-level configure script might be
> in
> > order, but my configuration needs are
> > simple enough that I have not been tempted to write one.
> >
> > With respect to solving the supposed problem of having separate source
> > trees for the two products, what is your
> > proposal? To eliminate SheepShaver's dependency upon the Basilisk II
> > components? It seems best to me to continue to
> > share the common code since, otherwise, changes would probably not
> > propagate correctly to both trees.
>
> Right, however the tangled web of symlinks makes development on either
> project difficult. Who would want to
> clean up a repo that several other projects depend on static file
> locations?
>
> I just ignore the symlinks and edit the files from the SheepShaver tree.
There is certainly room for improvement in the directory structure, but I
have not found this to be a great obstacle to development.


> >
> >> r>
> >>
> >> The SheepShaver project is not responsible for the design of Mac O.S.,
> >> and Apple is not
> > he classic versions anymore. If you do not like it, consider using a
> > different operating system. (What do you think
> > of
> > Haiku?)
>
> The *SheepShaver* interface, not the MacOS classic UI.
>
> Are you talking about the configuration editor? It has memory leaks and
other problems, and nobody seems to need it anyway, so I disable it
whenever I compile SheepShaver. It is much easier to edit the configuration
file.


>
> Given the responses above, and the complete lack of activity on the mailing
> list over the years... it seems like there
> really isn't any interest in keeping the project alive as an evolving open
> source application. (which may also explain
> why there has been little interest over the years)
>
> The project is not dead. The issue is more that it does not require much
evolution in order to suit people's needs. I needed to make some changes to
an internal version of SheepShaver about a year ago in order to support
compilation on 64-bit architectures, and Alexei made similar changes at
about the same time to the active tree, but there simply aren't many things
left to be done. We had a flurry of commits (all from Alexei) this past
winter that fixed a number of problems.

There are some big issues that everybody would like to see addressed, but
they do not stop SheepShaver from working most of the time, and they are so
difficult to solve that it is hard to justify spending time on them.

The structural changes that you propose to the project would break a lot of
compatibility with people's custom build and patching systems.  If you want
to evolve the project as you describe, it might be best to check out the
sources and then to start a new repository of your choice elsewhere after
you complete the restructuring that you have in mind.


> I'm trying to be helpful here and maybe help nudge things into a more
> active
> position. (I wouldn't be making these
> emails if I wasn't interested in putting some work into the project)
>
> What deficiencies in the product caused you to become interested in
helping with the development? If your complaint is not about the memory
management, it might be easily fixable. In fact, judging from my
experience, if you put a few hours into trying to correct the problem,
Alexei will commit a fix for the problem before you finish yours. This has
happened for me about four times.

What host operating system are you using, by the way?


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

[Alexander v. G. <kal...@un...>]

On 15.06.2012 09:45, Frank Trampe wrote:
> On Fri, Jun 15, 2012 at 8:43 AM, Alexander von Gluck 
> <kal...@un... [4]> wrote:
>
>> Good morning,
>>
>> I've been a off and on user of SheepShaver and Basilisk II for *years* 
>> (and
>> years, and years). It offers decent
>> emulation and is the best emulator out there for classic MacOS.
>>
>> Over the last 5+ years... not a lot has changed. Here is my take on some 
>> of
>> the current limitations of the project:
>>
>>  * CVS
>>    Most projects left cvs for other version control software years ago. 
>> Much
>> better source revision control software
>>    exist. If there aren't many developers out there who know how to use 
>> the
>> revision tracking software for a project...
>>    no one will know how to (or want) to contribute.
>
> The instructions on the download page work quite well. They may have been 
> updated since you last checked (although at
> least five years ago).
>
> cvs is not any more difficult to use than other revision control systems. 
> It lacks some of the features of svn and
> git, but those are not necessary for a project with so few contributors 
> and so few commits.

This seems like a self-fulfilling prophecy. Why do we have so few commits 
and interest? why should we move away from
a 21-year old overly complex version control software that no one uses 
anymore?

> The project does not need contributors who cannot figure out how to use 
> cvs. It does not lack for features. It just
> needs some work on the memory access stuff, which is the sort of thing 
> that is so complicated that only somebody who
> has already been a long-time contributor to the project could do it.

Open source development is an evolving ecosystem, a healthy project has 
users come and go improving parts they find
interesting.

Assuming someone wouldn't know how to write an MMU to perform physical to 
virtual address translation based on the
fact that they don't know how to use a 21 year old version control system 
which hasn't seen a major update in 6+ years
is a pretty strange assumption.

>>  * Complexity
>>    I remember being an early user and struggling figuring out how to 
>> compile
>> SheepShaver. Needing to check out
>>    two different source trees and have a script smash them together via
>> symlinks was pretty hard to figure out.
>
> This is quite simple now. You check out the two source trees in the same 
> directory, change to the SheepShaver
> directory, run make links, and then build for your platform. I do not need 
> to make any changes in the Basilisk II
> tree
> as mentioned in the instructions. A top-level configure script might be in 
> order, but my configuration needs are
> simple enough that I have not been tempted to write one.
>
> With respect to solving the supposed problem of having separate source 
> trees for the two products, what is your
> proposal? To eliminate SheepShaver's dependency upon the Basilisk II 
> components? It seems best to me to continue to
> share the common code since, otherwise, changes would probably not 
> propagate correctly to both trees.

Right, however the tangled web of symlinks makes development on either 
project difficult. Who would want to
clean up a repo that several other projects depend on static file locations?

>
>> r>
>>
>> The SheepShaver project is not responsible for the design of Mac O.S., 
>> and Apple is not
> he classic versions anymore. If you do not like it, consider using a 
> different operating system. (What do you think
> of
> Haiku?)

The *SheepShaver* interface, not the MacOS classic UI.


Given the responses above, and the complete lack of activity on the mailing 
list over the years... it seems like there
really isn't any interest in keeping the project alive as an evolving open 
source application. (which may also explain
why there has been little interest over the years)

I'm trying to be helpful here and maybe help nudge things into a more active 
position. (I wouldn't be making these
emails if I wasn't interested in putting some work into the project)

  -- Alex

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

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

On Fri, Jun 15, 2012 at 8:43 AM, Alexander von Gluck
<kal...@un...>wrote:

> Good morning,
>
> I've been a off and on user of SheepShaver and Basilisk II for *years* (and
> years, and years). It offers decent
> emulation and is the best emulator out there for classic MacOS.
>
> Over the last 5+ years... not a lot has changed. Here is my take on some of
> the current limitations of the project:
>
>  * CVS
>    Most projects left cvs for other version control software years ago.
> Much
> better source revision control software
>    exist. If there aren't many developers out there who know how to use the
> revision tracking software for a project...
>    no one will know how to (or want) to contribute.
>

The instructions on the download page work quite well. They may have been
updated since you last checked (although at least five years ago).

cvs is not any more difficult to use than other revision control systems.
It lacks some of the features of svn and git, but those are not necessary
for a project with so few contributors and so few commits.

The project does not need contributors who cannot figure out how to use
cvs. It does not lack for features. It just needs some work on the memory
access stuff, which is the sort of thing that is so complicated that only
somebody who has already been a long-time contributor to the project could
do it.


>  * Complexity
>    I remember being an early user and struggling figuring out how to
> compile
> SheepShaver. Needing to check out
>    two different source trees and have a script smash them together via
> symlinks was pretty hard to figure out.
>

This is quite simple now. You check out the two source trees in the same
directory, change to the SheepShaver directory, run make links, and then
build for your platform. I do not need to make any changes in the Basilisk
II tree as mentioned in the instructions. A top-level configure script
might be in order, but my configuration needs are simple enough that I have
not been tempted to write one.

With respect to solving the supposed problem of having separate source
trees for the two products, what is your proposal? To eliminate
SheepShaver's dependency upon the Basilisk II components? It seems best to
me to continue to share the common code since, otherwise, changes would
probably not propagate correctly to both trees.


>  * UI
>    The UI of sheepshaver is dated and complex. Usage is difficult for new
> users .
>
> The SheepShaver project is not responsible for the design of Mac O.S., and
Apple is not maintaining the classic versions anymore. If you do not like
it, consider using a different operating system. (What do you think of
Haiku?)


> Given the limitations above, the following solutions exist and could
> greatly
> improve development with little cost:
>
>  * CVS
>    Migrate to a newer version control software.
>    Most newer version control sofware allows imports of cvs to ensure
> commit
> history is not lost.
>    I have a git repo on my desktop with the SheepShaver sources migrated to
> it.
>  * Complexity
>    Combine Basilisk II code into SheepShaver. While I see the reasoning
> previously for keeping them separate
>    (development on Basilisk can be kept in one place), there really isn't a
> need anymore for the complex
>    symlinking of files as long term it causes *way* more confusion. Once
> again, I have a local SheepShaver
>    git repo with the Basilisk II code integrated.
>  * UI
>    Improving the UI would attract new users.
>
> Bonus:
>  * Work on porting the SheepShaver BeOS code to Haiku.
>
>
> Thoughts? As the Macintosh classic stuff quickly disappears into history,
> having a modern stable emulator would
> be a very good thing :)
>
>  Thanks! (and thanks for all the work over the years on SheepShaver and
> Basilisk II!
>    -- Alex
>
>
> ------------------------------------------------------------------------------
> 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] Thoughts on SheepShaver and Basilisk II

[Alexander v. G. <kal...@un...>]

Good morning,

I've been a off and on user of SheepShaver and Basilisk II for *years* (and 
years, and years). It offers decent
emulation and is the best emulator out there for classic MacOS.

Over the last 5+ years... not a lot has changed. Here is my take on some of 
the current limitations of the project:

  * CVS
    Most projects left cvs for other version control software years ago. Much 
better source revision control software
    exist. If there aren't many developers out there who know how to use the 
revision tracking software for a project...
    no one will know how to (or want) to contribute.
  * Complexity
    I remember being an early user and struggling figuring out how to compile 
SheepShaver. Needing to check out
    two different source trees and have a script smash them together via 
symlinks was pretty hard to figure out.
  * UI
    The UI of sheepshaver is dated and complex. Usage is difficult for new 
users .


Given the limitations above, the following solutions exist and could greatly 
improve development with little cost:

  * CVS
    Migrate to a newer version control software.
    Most newer version control sofware allows imports of cvs to ensure commit 
history is not lost.
    I have a git repo on my desktop with the SheepShaver sources migrated to 
it.
  * Complexity
    Combine Basilisk II code into SheepShaver. While I see the reasoning 
previously for keeping them separate
    (development on Basilisk can be kept in one place), there really isn't a 
need anymore for the complex
    symlinking of files as long term it causes *way* more confusion. Once 
again, I have a local SheepShaver
    git repo with the Basilisk II code integrated.
  * UI
    Improving the UI would attract new users.

Bonus:
  * Work on porting the SheepShaver BeOS code to Haiku.


Thoughts? As the Macintosh classic stuff quickly disappears into history, 
having a modern stable emulator would
be a very good thing :)

  Thanks! (and thanks for all the work over the years on SheepShaver and 
Basilisk II!
    -- Alex