Cameron Kaiser has written up a nice survey on some windowing systems that can run under OS/MP or SunOS https://oldvcr.blogspot.com/2022/10/if-one-guis-not-enough-for-your-sparc.html
Sunview was a toolkit - a really nice one in my opinion, every api had a set of defaults and a key, so you could call sv_whatever(SV_DONE) and did whatever with the default values. But you could override the defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It kept the system from being very verbose. People like Sunview's api enough that there was an Xview toolkit which was Sunview ported to X10/X11. On Mon, Oct 31, 2022 at 11:21:40AM -0700, Kevin Bowling wrote: > Cameron Kaiser has written up a nice survey on some windowing systems > that can run under OS/MP or SunOS > https://oldvcr.blogspot.com/2022/10/if-one-guis-not-enough-for-your-sparc.html -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
Larry McVoy writes:
> Sunview was a toolkit - a really nice one in my opinion, every api had
> a set of defaults and a key, so you could call sv_whatever(SV_DONE)
> and did whatever with the default values. But you could override the
> defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It
> kept the system from being very verbose.
>
> People like Sunview's api enough that there was an Xview toolkit which
> was Sunview ported to X10/X11.
Yeah, but it had its own issues. I did an emergency late night and weekend
consulting contract with Sun because Xview kept crashing. Turns out that
the code had some very suspect pointer dereferencing that worked until the
SPARC processors came along and barfed at unaligned accesses.
Jon
On Mon, Oct 31, 2022 at 3:18 PM Jon Steinhart <jon@fourwinds.com> wrote:
> Larry McVoy writes:
> > Sunview was a toolkit - a really nice one in my opinion, every api had
> > a set of defaults and a key, so you could call sv_whatever(SV_DONE)
> > and did whatever with the default values. But you could override the
> > defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It
> > kept the system from being very verbose.
> >
> > People like Sunview's api enough that there was an Xview toolkit which
> > was Sunview ported to X10/X11.
>
> Yeah, but it had its own issues. I did an emergency late night and weekend
> consulting contract with Sun because Xview kept crashing. Turns out that
> the code had some very suspect pointer dereferencing that worked until the
> SPARC processors came along and barfed at unaligned accesses.
That sounds like a ton of codebases, though. I remember trying to port an
APL interpreter to 64-bit, and giving up; too much type puning of pointers
through int's.
- Dan C.
On Mon, Oct 31, 2022 at 12:17:59PM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> > Sunview was a toolkit - a really nice one in my opinion, every api had
> > a set of defaults and a key, so you could call sv_whatever(SV_DONE)
> > and did whatever with the default values. But you could override the
> > defaults like so sv_whatever(SV_SOMEKEY, some_value, SV_DONE). It
> > kept the system from being very verbose.
> >
> > People like Sunview's api enough that there was an Xview toolkit which
> > was Sunview ported to X10/X11.
>
> Yeah, but it had its own issues. I did an emergency late night and weekend
> consulting contract with Sun because Xview kept crashing. Turns out that
> the code had some very suspect pointer dereferencing that worked until the
> SPARC processors came along and barfed at unaligned accesses.
Oh yeah, been there, fixed that.
My favorite SunView story was the day I was working in the Pentagon (I was ron@hq.af.mil for a while). One of the Sun workstations had a Sunview screen lock running and the guy I was visiting was on the phone. I told him I’d just unlock the thing myself. I promptly set forth to do so and got it open. He quickly said, “I have to hang up and go check on something,” and came over and asked how I’d done that. The screen lock was just a very large window forced to the top of everything on the screen. If you hit the hot key to iconify it, you had a fraction of a second to interact before it reasserted itself. So you keep hitting iconify and maybe getting a letter or two typed into one of the one terminal windows at a time. You run ps, find the pid of the screen lock process, and kill it. -Ron
[-- Attachment #1: Type: text/plain, Size: 473 bytes --] On 10/31/22 1:21 PM, Dan Cross wrote: > That sounds like a ton of codebases, though. I remember trying to port > an APL interpreter to 64-bit, and giving up; too much type puning of > pointers through int's. This reminds me of the stories I've heard about Microsoft's inability to port Pinball to /their/ 64-bit processor, the Itanium. No, not their copy of /AMD/'s 64-bit extension on Intel's x86 architecture. ;-) -- Grant. . . . unix || die [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4017 bytes --]
On Mon, 31 Oct 2022 at 22:55, Grant Taylor via TUHS <tuhs@tuhs.org> wrote: > > This reminds me of the stories I've heard about Microsoft's inability to > port Pinball to /their/ 64-bit processor, the Itanium. (?) Itanium was Intel's, not Microsoft's. > No, not their copy of /AMD/'s 64-bit extension on Intel's x86 > architecture. ;-) Again, not MICROS~1: Intel. MS is the reason Intel supports x86-64. When it saw that Itanium was failing, just like i860, just like iAPX-32, Intel built its own 64-bit extension to x86-32, to compete with AMD64. MS told Intel: look, we are already supporting *one* deadbeat unprofitable 64-bit arch of yours (i.e. Itanic.) We're not supporting *two*. No. You make it compatible with AMD's, because we're doing just one 64-bit x86 and we're already working on it. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
[-- Attachment #1: Type: text/plain, Size: 875 bytes --] I extensively researched this; there are infact copies of Pinball for 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s Pinball had problems relating to 64-bit FPU precision (and this can actually be reproduced by fiddling with FPU flags), but it did ship in Windows XP x64 Professional. Michael On Mon, Oct 31, 2022 at 5:55 PM Grant Taylor via TUHS <tuhs@tuhs.org> wrote: > On 10/31/22 1:21 PM, Dan Cross wrote: > > That sounds like a ton of codebases, though. I remember trying to port > > an APL interpreter to 64-bit, and giving up; too much type puning of > > pointers through int's. > > This reminds me of the stories I've heard about Microsoft's inability to > port Pinball to /their/ 64-bit processor, the Itanium. > > No, not their copy of /AMD/'s 64-bit extension on Intel's x86 > architecture. ;-) > > > > -- > Grant. . . . > unix || die > > [-- Attachment #2: Type: text/html, Size: 1328 bytes --]
[-- Attachment #1: Type: text/plain, Size: 669 bytes --] On 11/2/22 2:55 AM, Michael Casadevall wrote: > I extensively researched this; there are infact copies of Pinball for > 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s Which 64-bit platforms? 64-bit x86 and / or 64-bit Itanium? I've not watched the video yet (today). > Pinball had problems relating to 64-bit FPU precision (and this can > actually be reproduced by fiddling with FPU flags), but it did ship in > Windows XP x64 Professional. My understanding is that Windows XP x64 Professional is 64-bit x86 and not Itanium. There is also a chance that I'm misremembering things. -- Grant. . . . unix || die [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4017 bytes --]
On 2 Nov 2022 09:34 -0600, from tuhs@tuhs.org (Grant Taylor via TUHS): >> Pinball had problems relating to 64-bit FPU precision (and this can >> actually be reproduced by fiddling with FPU flags), but it did ship in >> Windows XP x64 Professional. > > My understanding is that Windows XP x64 Professional is 64-bit x86 and not > Itanium. Per Wikipedia, "Windows XP 64-Bit Edition" was for Intel's Itanium IA-64 architecture; whereas "Windows XP Professional x64 Edition" was for AMD's x86-64 architecture. https://en.wikipedia.org/wiki/Windows_XP#Editions You've just got to love it when two wildly distinct, yet highly similar, things are named almost, but not quite, the same. -- 🪶 Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
[-- Attachment #1: Type: text/plain, Size: 949 bytes --] On Wed, Nov 2, 2022 at 11:37 AM Grant Taylor via TUHS <tuhs@tuhs.org> wrote: > On 11/2/22 2:55 AM, Michael Casadevall wrote: > > I extensively researched this; there are infact copies of Pinball for > > 64-bit platforms: https://www.youtube.com/watch?v=3EPTfOTC4Jw&t=47s > > Which 64-bit platforms? 64-bit x86 and / or 64-bit Itanium? > > I've not watched the video yet (today). > > Both actually, since Microsoft included pinball.exe on the Itanium install disk. Works too (although there are complications) > > Pinball had problems relating to 64-bit FPU precision (and this can > > actually be reproduced by fiddling with FPU flags), but it did ship in > > Windows XP x64 Professional. > > My understanding is that Windows XP x64 Professional is 64-bit x86 and > not Itanium. > > There is also a chance that I'm misremembering things. > > > No, its just the worst product naming scheme known to man. > > -- > Grant. . . . > unix || die > > [-- Attachment #2: Type: text/html, Size: 1797 bytes --]
On Sat, 5 Nov 2022 at 11:38, Michael Casadevall <michael@casadevall.pro> wrote: > > No, its just the worst product naming scheme known to man. To be fair -- something I rarely feel in connection with MICROS~1 -- when XP came out in 2002, AMD Sledgehammer did not exist yet. There was no x86-64 and the only Intel 64-bit architecture was Itanium. So I feel that they have some excuse. We should actually give MS _some_ credit on this, because it's only thanks to MS that Intel didn't do a totally separate incompatible 64-bit x86 extension. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053