New answers tagged operating-system
3
One other difference: Xenix 2.3.2 did not have a block buffer cache. Every version of SCO Unixs I've used did.
Consequence: On an IBM PS/2 model 80 (?, 20 MHz 386, Micro Channel) the max throughput to the hard drive was 35 KB/s. On an AST Research 486 with a DPT SmartCache SCSI controller (high end for 1992!) we maxed out at 45 KB/s.
16
Using SCO UNIX describes the history of XENIX and SCO UNIX and provides a brief summary of the technical differences.
As Raffzahn explains, SCO UNIX is the successor to XENIX. XENIX is a licensed version of UNIX; it was called XENIX because initially, AT&T didn’t allow its licensees to use the UNIX trademark. This was relaxed in 1989, which allowed SCO ...
7
What exactly were the technical advantages that made their Unix worth more than Xenix?
For most parts: The Name. Otherwise it's simply the next release of SCO's unixoide OS.
They were only sold in parallel for a short time (ca 1989/90). While the latest Xenix version was based on System V R2.3, SCO Unix started out as System V R3.2. But using the same ...
3
If you want to print a string (terminated with a NUL (000)) suggest the following:
string: .asciz "the quick brown ..."
mov #1000,sp ; init stack
mov #string,R0 ; pass string as argument
jsr pc,Print ; to Print function
...
Print:mov r1,-(sp) ; save R1
br 20$ ; jump to NUL test
10$: ...
1
As you go back.in time, the nature of the OS itself changes.
In earlier computing eras, the OS was often (not always but often) closer to a set of callable commands - a library and framework, not an overarching *visor.
That meant that it was much more often down to the application to use what was useful, and add for itself whatever else it wanted that the OS ...
2
Although not the earliest example, in 1973, IBM released APL.SV (A Programming Language | Shared Variables). Variables (of any number of dimensions) could be shared between instances (effectively threads) of APL programs running on different terminals. Not mentioned in the wiki article linked to below is that APL.SV ran in supervisor mode, so there was no ...
12
It wasn't called "threads", but as soon as interrupts were invented - which was in the mid 1950's - which was also before (even primitive) operating systems evolved to manage them - user programs handled them. Which meant ordinary programmers (for the time) were writing concurrent programs "in a single address space" for those computers ...
13
I think the Apollo Guidance Computer has a shot at making this claim. It may not be the first, but it's certainly one of the better documented early systems. The AGC had to juggle dozens of things at once. It was the main clock, and the navigation system, it ran the displays, and the radar, and the telemetry uplink, and controlled the engines, all ...
3
I think Muddle allowed multithreaded evaluation within a single address space. It had to do with evaluating A and B where A takes ten minutes to evaluate to true and B takes a millisecond to evaluate to false. Wouldn't it be smart to evaluate them quasi concurrently? This was built at MIT in the 1971-1972 timeframe.
https://en.m.wikipedia.org/wiki/MDL_(...
3
Despite the elaborate text, there is no clear answerto be given, as this is more about machine capabilities as it is about OS features.
By that definition, when did the first system add explicit support for threads?
Which again would need a definition what an explicit support is. An OS supporting shared memory between processes/tasks/ - as well as code ...
14
Ah, memories of Computer Science 412.
In the Digital Research family of operating systems, MP/M II (1981, possibly earlier variants, but this is what I found quickly) as noted in the programmer's guide already allowed for processes to create sub-processes, had mutual exclusion queues/semaphores, etc. Section 1.2.2, Queue Management, gives an overview of how ...
answered Feb 11 at 18:52
manassehkatz-Moving 2 Codidact
6,8941 gold badge17 silver badges41 bronze badges
10
Threads seem to have first appeared in IBM's mainframe operating system OS/360 MVT in 1967, although they were called "tasks" at the time.
MP/M (1981) allowed a process to create additional sub-processes which amounted to threads. Since MP/M ran on hardware without memory protection, thread programming would have been somewhat more risky than it is ...
20
As a matter of fact, IBM did introduce support not only for multiple parallel processes, but also for multi-threading (called "sub-tasks") in their Multiprogramming with a Variable number of Tasks (MVT) variant of OS/360. That is the earliest mention of multi-threading concept in a production system I could find. MVT variant was announced AFAIK ...
17
Any operating system that supports multiple execution contexts within a shared address space has "threads", even if they don't call it that. Because that's all that threads are.
For example, the exec on many ICL 1900s systems supported what they called "subprogramming", in which a program could start an independently-executing entity in ...
13
That question is rather wide, as there wasn't a mainframe OS but many. Equally important, headers were not made by the OS, but whatever SPOOL system was used. And there were many.
Here a typical MVS(ish) cover page:
Depending on organisational structure of OS and SPOOL-system a cover (or SPOOL) page may include:
Job Name
User Name
Account Number
These ...
Top 50 recent answers are included
