Menu
▾
▴
basilisk-devel
|
From: Robert M. <mr...@gm...> - 2012-06-16 06:29:06
|
Wow. I spent a day on the Civ 2 "Eternal War" and now I have 30 messages about SS! I'll have to respond in more than one message, but I'll try not to repeat too much. On 6/15/12, Alexander von Gluck <kal...@un...> wrote: > * CVS > Most projects left cvs for other version control software years ago. > Much better source revision control software exist. [...] On the CVS issue, I think it would be kind of nice to have something like Git's "Fork and Pull model"... but I ALSO think that anyone who would make useful changes to BasII or SS should be able to type "cvs diff -uN | gzip > patch.txt.gx" Perhaps more of the development process (like this issue of submitting improvements back upstream) should be more well-documented. -- 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 |
|
From: Robert M. <mr...@gm...> - 2012-06-16 06:47:59
|
On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck wrote: >> 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) Wow, you're not kidding -- I found four other forks of SheepShaver on GitHub! Regardless of the rest of the questions, like how to improve the UI or make development easier, we should definitely check these out -- there's obviously a lot of creative energy out there. Some of them could probably benefit from the work we've done. I noticed one version has "enable JIT on 64-bit MacOS" as their latest change, and we've done other improvements since then. Any Mac users using any of those forks would want my CD-ROM eject fix, for example. -- 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 |
|
From: Alexei S. <ale...@gm...> - 2012-06-16 15:53:14
|
On Sat, Jun 16, 2012 at 2:47 AM, Robert Munafo <mr...@gm...> wrote: > On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck wrote: > >> 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) > > Wow, you're not kidding -- I found four other forks of SheepShaver on > GitHub! > > Regardless of the rest of the questions, like how to improve the UI or > make development easier, we should definitely check these out -- > there's obviously a lot of creative energy out there. Some of them > could probably benefit from the work we've done. I noticed one version > has "enable JIT on 64-bit MacOS" as their latest change, and we've > done other improvements since then. > > Any Mac users using any of those forks would want my CD-ROM eject fix, > for example. > I think regardless of any new SCM we switch to, we definitely need a better process to getting code to upstream. In the past, I've tried to encourage people to send patches to this list for this, so that we could discuss them if necessary and I would land them. This model works very well for some other projects, like ffmpeg. But it hasn't really worked too well here. Often times people don't send patches - either they post them to emaculation.com forums and I need to periodically monitor these and look for these gems - or they don't share them and just post builds there - or they commit them to their own git works without telling anyone. You may argue that the last workflow should be fine - i.e. people committing stuff to their own forks and upstream (me) then looking over what's been done and pulling stuff I'm interested in. I disagree. A lot of such changes don't provide enough context as to what they're fixing or why that change is being made. And I don't feel comfortable merging in stuff randomly without understanding it. There needs to be a place for discussion. 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 - instead of checking the cache just at the beginning, check it at every iteration so that presumably if the next pc is in the cache, we could get it from there. Maybe. I'm not sure that my description is correct - the code is pretty complicated there. Does it really improve performance? Something like this could actually degrade performance. I don't see any reference to benchmarks or improvements in the commit description. When I try running some random benchmark programs I have lying around, I don't see any difference. I can't justify pulling that into upstream unless I know what improvement that provides - otherwise it's just unnecessary code churn. -Alexei |
|
From: Giulio P. <giu...@gm...> - 2012-06-16 16:54:44
|
Il 16/06/2012 17:52, Alexei Svitkine ha scritto: > > > On Sat, Jun 16, 2012 at 2:47 AM, Robert Munafo <mr...@gm... > <mailto:mr...@gm...>> wrote: > > On Fri, Jun 15, 2012 at 12:08 PM, Alexander von Gluck wrote: > >> 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) > > Wow, you're not kidding -- I found four other forks of SheepShaver > on GitHub! > > Regardless of the rest of the questions, like how to improve the UI or > make development easier, we should definitely check these out -- > there's obviously a lot of creative energy out there. Some of them > could probably benefit from the work we've done. I noticed one version > has "enable JIT on 64-bit MacOS" as their latest change, and we've > done other improvements since then. > > Any Mac users using any of those forks would want my CD-ROM eject fix, > for example. > > > I think regardless of any new SCM we switch to, we definitely need a > better process to getting code to upstream. In the past, I've tried to > encourage people to send patches to this list for this, so that we could > discuss them if necessary and I would land them. This model works very > well for some other projects, like ffmpeg. > > But it hasn't really worked too well here. Often times people don't send > patches - either they post them to emaculation.com > <http://emaculation.com> forums and I need to periodically monitor these > and look for these gems - or they don't share them and just post builds > there - or they commit them to their own git works without telling anyone. Github "Network" facilities will greatly help you with this: people commits in their own repositories and you can see how those changes relate to yours. > You may argue that the last workflow should be fine - i.e. people > committing stuff to their own forks and upstream (me) then looking over > what's been done and pulling stuff I'm interested in. I disagree. A lot > of such changes don't provide enough context as to what they're fixing > or why that change is being made. And I don't feel comfortable merging > in stuff randomly without understanding it. There needs to be a place > for discussion. In github (but also in bare git) there is also the "Pull request" method that is: if someone wants to contribute a set of commits with you, just selects the set of commits, writes a few notes about them and send the request to you. You can ask for further details in a forum-like discussion and when you are convinced can accept or reject the changes. It works quite fine. > 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 - instead of checking the cache just at the beginning, check > it at every iteration so that presumably if the next pc is in the cache, > we could get it from there. Maybe. I'm not sure that my description is > correct - the code is pretty complicated there. Does it really improve > performance? Something like this could actually degrade performance. I > don't see any reference to benchmarks or improvements in the commit > description. When I try running some random benchmark programs I have > lying around, I don't see any difference. I can't justify pulling that > into upstream unless I know what improvement that provides - otherwise > it's just unnecessary code churn. > > -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 |
|
From: howard s. <how...@ho...> - 2012-06-16 19:42:20
|
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. 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. 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. -USB support. -Video acceleration on the host. -Memory management allowing running Mac OS above 9.0.4. -More opcodes supported, allowing more applications to work. (Office comes to mind). -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. -Improve SCSI support. 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. -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. Best regards, Ronald P. Regensburg and Howard Spoelstra |
|
From: Robert M. <mr...@gm...> - 2012-06-16 19:54:20
|
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 |
|
From: Alexei S. <ale...@gm...> - 2012-06-16 20:00:32
|
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 > |
|
From: Frank T. <fra...@gm...> - 2012-06-16 20:59:14
|
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 > > |
|
From: C.W. B. <com...@ho...> - 2012-06-16 21:24:47
|
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? |
|
From: howard s. <how...@ho...> - 2012-06-16 22:03:55
|
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 |
|
From: Josh J. <jj...@gm...> - 2012-06-18 03:42:17
|
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 |
|
From: Robert M. <mr...@gm...> - 2012-06-18 06:41:25
|
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 |
|
From: Josh J. <jj...@gm...> - 2012-06-18 09:34:12
|
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> |
|
From: Charles S. <bas...@ch...> - 2012-06-18 10:25:56
|
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 |
|
From: Charles S. <bas...@ch...> - 2012-06-18 10:25:13
|
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 |
|
From: Alexei S. <ale...@gm...> - 2012-06-18 12:01:29
|
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 |
|
From: Ronald P. R. <ron...@xs...> - 2012-06-18 13:04:57
|
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 > |
|
From: Robert M. <mr...@gm...> - 2012-06-18 16:54:53
|
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 |
|
From: Frank T. <fra...@gm...> - 2012-06-18 16:59:56
|
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
>
|
|
From: Frank T. <fra...@gm...> - 2012-06-18 17:00:39
|
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
>>
>
>
|
|
From: Robert M. <mr...@gm...> - 2012-06-18 17:05:02
|
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 |
|
From: Charles S. <bas...@ch...> - 2012-06-18 17:23:02
|
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 |
|
From: Robert M. <mr...@gm...> - 2012-06-18 17:30:33
|
On 6/18/12, Alexei Svitkine <ale...@gm...> wrote: > 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/ That one appears to implement only bitmaps within PICT files, not the full QuickDraw opcode set needed for B2 and SS. I quote from http://paintlib.cvs.sourceforge.net/viewvc/paintlib/paintlib/common/plpictdec.cpp?view=markup "This class decodes macintosh PICT files with 1,2,4,8,16 and 32 bits per pixel as well as PICT/JPEG. If an alpha channel is present in a 32-bit-PICT, it is decoded as well. The PICT format is a general picture file format and can contain a lot of other elements besides bitmaps. These elements are ignored." I once found a project trying to implement QuickDraw emulation for a similar purpose, I don't remember how complete it was. It's important that it be as small as possible (no external libraries except what we can count on from Apple, no code for other formats like GIF, BMP, DICOM, etc.) and of course all open source. I do agree with the general idea, that adding QuickDraw emulation in the host side would be a good idea to investigate. -- 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 |
|
From: Charles S. <bas...@ch...> - 2012-06-18 17:37:33
|
On Jun 18, 2012, at 12:30 PM, Robert Munafo wrote: > On 6/18/12, Alexei Svitkine <ale...@gm...> wrote: >> 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/ > > That one appears to implement only bitmaps within PICT files, not the > full QuickDraw opcode set needed for B2 and SS. I quote from > http://paintlib.cvs.sourceforge.net/viewvc/paintlib/paintlib/common/plpictdec.cpp?view=markup > > "This class decodes macintosh PICT files with 1,2,4,8,16 and 32 bits > per pixel as well as PICT/JPEG. If an alpha channel is present in a > 32-bit-PICT, it is decoded as well. The PICT format is a general > picture file format and can contain a lot of other elements besides > bitmaps. These elements are ignored." But this is only for pasteboard support between the emulated and host systems, right? Do we really need 100% compatibility for that? As long as a PICT image on the emulated pasteboard gets translated to a TIFF or PNG or something on the host pasteboard and vice-versa 99% of the time, any rare corner cases should be only a minor inconvenience. Charles |
|
From: Jean-Pierre <cho...@fr...> - 2012-06-18 20:37:37
|
Le 18 juin 2012 à 19:37, Charles Srstka a écrit : > But this is only for pasteboard support between the emulated and host systems, right? Do we really need 100% compatibility for that? As long as a PICT image on the emulated pasteboard gets translated to a TIFF or PNG or something on the host pasteboard and vice-versa 99% of the time, any rare corner cases should be only a minor inconvenience. BTW, the patch I've just posted seems to work also for pictures, as I could copy a sample image from Picture Viewer in Mac OS 9 and paste it in Mac OS X's Preview. I have no picture editor in my classic environment, so I can't tell for pasting into Classic, but it might worth trying. -JP. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X