31 Oct
2022
31 Oct
'22
7:21 p.m.
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.h…
31 Oct
31 Oct
8:14 p.m.
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.h…
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
8:17 p.m.
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
8:21 p.m.
On Mon, Oct 31, 2022 at 3:18 PM Jon Steinhart <jon(a)fourwinds.com> wrote:
Larry McVoy writes:
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.
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. 
10:52 p.m.
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
1 Nov
1 Nov
12:02 p.m.
On Mon, 31 Oct 2022 at 22:55, Grant Taylor via TUHS <tuhs(a)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(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
2 Nov
2 Nov
9:55 a.m.
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(a)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
4:34 p.m.
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
4:44 p.m.
On 2 Nov 2022 09:34 -0600, from tuhs(a)tuhs.org (Grant Taylor via TUHS):
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?”
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.
5 Nov
5 Nov
11:38 a.m.
On Wed, Nov 2, 2022 at 11:37 AM Grant Taylor via TUHS <tuhs(a)tuhs.org> wrote:
No, its just the worst product naming scheme known to man.
On 11/2/22 2:55 AM, Michael Casadevall wrote:
Both actually, since Microsoft included pinball.exe on the Itanium install
disk. Works too (although there are complications)
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
12:21 p.m.
On Sat, 5 Nov 2022 at 11:38, Michael Casadevall <michael(a)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(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
31 Oct
31 Oct
8:26 p.m.
On Mon, Oct 31, 2022 at 12:17:59PM -0700, Jon Steinhart wrote:
Larry McVoy writes:
Oh yeah, been there, fixed that.
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. 
8:59 p.m.
My favorite SunView story was the day I was working in the Pentagon (I
was ron(a)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
731
days inactive
736
days old
12 comments
9 participants
participants (9)
-
Dan Cross -
Grant Taylor -
Jon Steinhart -
Kevin Bowling -
Larry McVoy -
Liam Proven -
Michael Casadevall -
Michael Kjörling -
Ronald Natalie