On 2024-04-10 3:55 Nightfox said...

I wonder how many people will be using ARM-based Wnidows machines though.
I've heard of Microsoft working on that, but at least right now, I haven't seen anyone using an ARM Windows machine, either at work or for personal use.

This might change with the recent Chineese ban on the use of non-chineese processors. The cores Huawei etc. use to mass produce processors are ARM.
I guess we will soon see a lot of personal laptops based on ARM produced for chineese market, that will eventually spread to other markets.

--
smk
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 20.11.1)
* Origin: X65.zone (21:1/222)

Gamgee wrote to Tiny <=-

I still use Wordperfect office for DOS at home because it does
converting) and work from home using dos.

Sweet!

Just what I got used to, and my fingers just know what keys to hit
without using menus.

At work I'm stuck with M$ office, so I'm slowly getting used to that
and will probably end up scrapping my dos setup eventually.

Shawn


... Forgive your enemies but never forget their faces

--- MultiMail/Linux v0.52
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/700)

On 12 Apr 2024 at 11:29a, Digital Man pondered and said...

Re: Re: Operating Systems
By: tenser to claw on Sat Apr 13 2024 02:39 am

There's a lot of software out there, written 20 or 30 years
ago, that made a lot of assumptions about the state of the
world; there were a lot of programmers who thought to
themselves in 1991, "Gee, the year 2038 is a long time from
now..." and took shortcuts.

Speaking for myself at least, I started using time_t types for storing dates and times in C programs in 1988 and wasn't even aware that it
would ever roll-over (go negative) at any point. I don't think I
actually realized that most time_t's are signed (can go negative) and
that for those systems (C libraries), dates before Jan-1-1970 are *suppoosed* to representable in that way (as negative valeus). [libraies that use unsigned time_t's cannot represent dates before Jan-1-1970] And I'm pretty sure it was 1992 when I did the math and realized that 2038
and 2106 are going to be problematic years for 32-bit time_t-based libraries/programs. It was certainly not discussed in the programming books or among C programmers of the era. We weren't taking shortcuts, we were just following the norms. Use of 64-bit integers for most things seemed excessive/wasteful and in many environments (e.g. 16-bit systems) not practical or even possible. --

Using time_t was less the "shortcut" issue that I was thinking
of, and more people doing things like casting back and forth
between various int types. Disciplined use of `time_t`, and
not making a lot of assumptions about size of that type, makes
the problem tractable in programs for which one has the source.

The VMS people warned us about this a long time ago; certainly
in the 80s. DEC engineering famously had a bug that they kept
open that said something like, "VMS dates won't work after the
year 9999."

I distinctly remember people talking about 2038 in the runup
to Y2K and the consensus was mostly, "meh, we'll fix it before
then." In the 32-bit era, we had more pressing issues, like
running out of address space, or the UID space rolling over on
big installations.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)