The is also the Windows Subsystem for Linux, which basically runs Linux under Windows. https://docs.microsoft.com/en-us/windows/wsl/ On 9/27/2021 9:07 AM, Joshua Rice via cctalk wrote:

On Mon, Sep 27, 2021 at 11:18 AM Alan Perry via cctalk < cctalk at classiccmp.org> wrote: When there is no relationship between the hardware and OS teams (i.e. the OS team chooses to adopt the hardware on their own) you can say the OS is adding support for that hardware platform. But more often than not, OS support is a big part of selling hardware. You seriously reduce your potential sales if your hardware doesn't run a popular operating system, and to ensure that your operating system(s) of choice will run on your hardware, you pay your own developers to do the port(s). At that point, it is very much a case of the hardware platforms supporting an OS. This is especially true when other operating system developers find themselves unable to support your hardware because the needed documentation isn't available. The situation is similar with add-on hardware that requires device drivers. If the documentation needed to write a device driver is unavailable, and the only available drivers came from the hardware maker, then it is definitely a case of the hardware maker supporting the OS. -ken

More like you sell the hardware, then write the software. Look at APPLE was 68000 now the Apple/386 style cpu. Hardware has no meaning. Never a fan of RISC or modern designs because you got speed by being able pipeline DRAM access, not because of RISC or what ever CPU of the day was. Ben.

On 2021-09-27 10:07, Joshua Rice via cctalk wrote (in part): I cannot agree.? Many developers ensure that their software runs under their particular distribution and then call it POSIX. Porting to UNIX systems, such as Solaris or macOS, can be difficult and tedious.? (Of course, this is not a Linux issue.) N.

On 9/27/21 3:30 PM, Zane Healy via cctalk wrote: The same can be, and was, said about Unix. IRIX, Solaris, SunOS, AIX, HP-UX, OpenServer, UnixWare, what have you. They were all Unix operating systems, if not actually licensed to use the Unix name. Yet they were as different from each other as different Linux distributions can be. Microsoft has even had this problem with Windows 3.x, Windows 9x, and NT / 2k. -- Grant. . . . unix || die

On 9/28/21 12:26 AM, Tor Arntsen via cctalk wrote: Kudos to you. I mean that sincerely and with respect. I'm not a developer by any stretch of the imagination. But I know from a Unix systems administrator standpoint, creating shell scripts / command structures (think HereDocs run through SSH redirection) that doing so in a cross platform way is non-trivial. I found the biggest hurtle was knowing what commands ~> syntax / utilities my target platforms (AIX 5~7, Solaris 8~10, OpenServer 5, UnixWare 7, Red Hat / CentOS 4~6, SuSE 7~9, Gentoo (~2008), FreeBSD (?), and others I don't remember) had in common. File paths and what command were one thing. Command flags ~> syntax was another. Elevating privilege to root via su or sudo or doas was ... tedious. Unfortunately I think that it's unreasonable reasonable to expect someone that has a myopic view of their singular platform to have any idea how to do things on other platforms as well as they can on their platform of choice. -- Is it reasonable to expect a mechanic that works on lawn mowers to be as proficient on tractor trailers or motorcycles? I don't think so. I would expect that someone that has a working understanding of any platform to be able to muddle their way through most other platforms. But muddling your way through something is definitely not the same level of support. So, I sincerely mean kudos to anyone that even attempts to do things on multiple platforms. I believe it's a laudable goal. I believe that each supported platform adds an order of magnitude of complexity to the overall task at hand. I had not considered what you are describing. But it sounds like a more development centric version of what I described above. I'd be interested in sharing a beverage and hearing (horror) stories. Hopefully I'd learn a thing or three. My year of the Linux desktop was '99. I switched from a release candidate of Windows 98 to Slackware '96 (an old book that someone lent me). I've almost completely used Linux as my chosen platform ever sense. I've moved around between Linux distros, but have always either directly used or SSHed to a Linux box for my core work. -- Grant. . . . unix || die

On 2021-09-28 02:26, Tor Arntsen via cctalk wrote (in part): Writing portable s/w may not be difficult but it takes some discipline on the part of the programmers.? Many programmers only have Linux distros so they (perhaps understandably) only develop in their environment. I have the same experience.? We produced s/w that ran on dozens of different UNIX and non-UNIX systems including embedded systems.? The main point was to write POSIX C-code (and stay away from the preprocessor).? Our main issue was that native compilers were not always as compliant as claimed.? We were fortunate in that our s/w was either back-end or embedded without the need -- read headache -- of GUI interfaces. N.

On 2021-09-27 11:46 p.m., ben via cctalk wrote: We've been through this before. No.

You're mixing up two unrelated things. int8_t is an integer type of 8 bits width. char is the type used for characters. While in many machines they are the same size, that isn't required. C compilers have been built for machines with non-8 bit characters, from the CDC 6600 to the PDP-10 and Cray-1 and various DSPs. GCC at one time (some of them still, I think) handled all these except the 6600. paul

Python does, its "int" type handles numbers of any size, so long as it fits in memory. If you create sufficiently large numbers it may take a while to do arithmetic operations, of course. "The nice thing about standards is that there are so many to choose from" -- Prof. David Clark, MIT. C certainly has been run on one's complement machines (CDC 6000 series) but I've heard it stated by some who would know that the current standard expects two's complement. Interestingly enough, floating point data is, in IEEE and a number of other formats, sign/magnitude encoded, not two's complement. Some old machines used one's complement for float, though. For extra credit, create a GCC back end for that design. :-) I think Von Neumann would agree; he picked 40 bits as I recall. There are all sorts of interesting word lengths out there; the strangest I've worked with is 27 bits one's complement. paul

Not a drum machine. Core memory, all solid state -- one of the first, and as far as I know the first commercial product with interrupts standard. Electrologica X1, from 1958. Also its successor the X8, around 1964. The X8 had a drum as a peripheral device, used in the THE operating system for paging virtual memory (512 k words). paul

On 9/28/2021 2:15 PM, ben via cctalk wrote: Hardly. FORTRAN: INTEGER*4 INTEGER*8 (and sometimes INTEGER*2 - e.g. Sun FORTRAN-77) was common, though never adopted as a standard. Also REAL vs. DOUBLE. COBOL: COMP-1 and COMP-2 for floating point: single and double precision. Pascal, Ada: specified range of values. How that actually got implemented would be implementation dependent. And more, I'm sure. As for any length of data, that becomes a cost/return question. Adding that capability would create no end of headaches for language implementation, so it isn't done. Instead, if one actually needed that, one would define a type (with methods) or a set of functions to accomplish that - and no doubt many exist out on the 'net. JRJ

REXX has had this ability from the start. It only does decimal arithmetic, but you can set the number of numeric digits used to whatever you want Dave

Nemo Nusquam via cctalk <cctalk at classiccmp.org>: It's especially frustrating when, after having put in the work, projects refuse even trivial patches for Solaris and derrivatives or sometimes even BSDs because 'who uses that anyway'. (I include the patches in pkgsrc instead.) Sijmen

On Mon, 25 Oct 2021 at 11:39, Peter Corlett via cctalk <cctalk at classiccmp.org> wrote: I think "Solaris and derivatives" was a easier way than saying SmartOS, Illumos and OpenIndiana as well as any poor souls running Solaris (some of which may be running older versions on Sparc kit) I'm... pretty sure SmartOS/Illumos are actively friendly to open source work - last I checked Joyent provided pkgsrc config to build around 20,000 packages and had a policy of trying to feed back changes upstream https://pkgsrc.joyent.com/install-on-illumos/ You could easily s/Solaris/Solaris,BSD,non(x86,arm,riscv),etc/ Its obviously entirely up to the members of a project to decide on what to spend their time, and specifically what they are interested in supporting, though if there is an active policy to not want to support certain platforms it would help to have a specific statement in the README to avoid other people wasting their time and annoying project members by sending in unwanted patches and then complaining that the patches are being ignored. If its a matter of the patches needing more work, then that's always a perennial problem, for just about all platforms and projects. Maybe submitters of patches orm some platforms need to do more work, so they should be told that tl;dr if there are hoops to jump through for some platform patches, indicate the hoops. If the path is closed, make it clear up front.. David

One major issue with any patch or code change is regression testing.? Any given change may fix a particular issue but what are the ramifications for the entire system across all circumstances. Though a change or fix may seem simple to integrate, the time is takes to fully vet that fix could take weeks depending on the system. On 10/27/2021 8:02 AM, Sijmen J. Mulder via cctalk wrote:

Assembly version August 25th 1991. - comp.os.minix newsgroup. C version October 5th 1991 - Linux Bible 8th edition. I started using Red Hat with version 6.2. For a while the server I put it on just sat there until I got around to making it a mail server. I still have the server but it was upgraded to BSD at some point. I doubt I have a backup anymore Bill

On Sep 27, 2021, at 8:03 AM, mazzinia--- via cctalk <cctalk at classiccmp.org> wrote: The real difference is in the emulators available under one or the other platform. Realistically, for many/most people, that?s the first thing to look at, are the Applications I need to run available for Linux, MacOS, or Windows. End result, many of us have all three, and others. Zane