<bslsk05>
en.m.wikipedia.org: Timeline of DOS operating systems - Wikipedia
<kazinsal>
ah, looks like the multitasking DOS got released for a few OEMs in Europe
<kazinsal>
and regular DOS 4.0 was only released for OEMs, no retail/upgrade version available
<geist>
holy crap that page has a ridiculous amount of detail
<kazinsal>
seriously
<kazinsal>
where'd my scrollbar go
<geist>
there’s a guy on youtube that has a series of videos on OS/2, early windows, dos, etc that has this level of detail. wouldn’t be surprised if he didn’t fill this in
k_hachig has quit [Quit: WeeChat 4.2.2]
edr has quit [Quit: Leaving]
theruran has quit [Quit: Connection closed for inactivity]
<GreaseMonkey>
i take one look at this channel and hot damn, DOS 4.0 (the interesting one) source code? yes please
<GreaseMonkey>
IIRC it was released some time between 3.2 and 3.3
<GreaseMonkey>
i played with it briefly i think on pcjs and honestly, i wish DOS took that route
<geist>
yah
gbowne1 has quit [Quit: Leaving]
masoudd has joined #osdev
Matt|home has joined #osdev
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
bradd has quit [Read error: Connection reset by peer]
bradd has joined #osdev
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
netbsduser has joined #osdev
netbsduser has quit [Remote host closed the connection]
netbsduser has joined #osdev
vaihome has joined #osdev
\Test_User has quit [Quit: e]
masoudd has quit [Remote host closed the connection]
\Test_User has joined #osdev
vaihome- has joined #osdev
carbonfiber has quit [Quit: Connection closed for inactivity]
vaihome has quit [Ping timeout: 246 seconds]
<GreaseMonkey>
...ok, looking a bit more into it and reading the blog post, it turns out it *is* the source for the less interesting MS-DOS 4.0, but also a binary beta for the more interesting one and some BIOS source code or at least IBMBIO source code: https://cloudblogs.microsoft.com/opensource/2024/04/25/open-sourcing-ms-dos-4-0/
<bslsk05>
cloudblogs.microsoft.com: Open sourcing MS-DOS 4.0 - Microsoft Open Source Blog
<kazinsal>
yeah, not the most interesting, but still neat
<kazinsal>
I'd love for them to FOSS up DOS 6.22
<kazinsal>
but I'd also like ten million dollars and to be 40 pounds lighter, and only one of those three things is possible
<bslsk05>
fuchsia.googlesource.com: zircon - Git at Google
<heat57>
this predates the zircon merge IIRC
<geist>
it does, but only because it played back the zircon.git history into it
<heat57>
yep
<geist>
but it's possible that didn't get replayed precisely right
<geist>
i'd check out the zircon repo
<heat57>
anyway: the gn build simply doesn't work anymore, the LK makefile seems to have a $(SPACE) variable that was broken in some GNU make update probably
<geist>
there was a magenta repo prior to that, but it got killed
<geist>
gn could be because it needs a newer or older version of gn than you have
<geist>
the space thing is surprising though
<heat57>
then toolchain problems galore, I think i'll try an era-appropriate (5.0? 6.0?) -elf toolchain that doesn't have default PIE and default ssp and ld bfd default etc
<geist>
there was a toolchain repo at the time where we were building our own gcc from
<bslsk05>
fuchsia.googlesource.com: third_party/gcc_none_toolchains - Git at Google
<nikolapdp>
well good luck
<nikolapdp>
wonder what you can even do with it
<heat57>
early magenta is a trivial build
<heat57>
before the gn merge and needing all the google tooling
<heat57>
and taking 2 hrs to fucking build
<nikolapdp>
geist: another interesting addition could be passing custom arguments to the configure script
<nikolapdp>
for your toolchains
<geist>
extracting zircon/magenta out of fuchsia dn building new things on top of it would be useful. it's somewhat specifically built to be system agnostic
<geist>
trouble is there's a fair amount of work to extract it back out of the build system, but it's pretty surmountable
<geist>
toolchain wise basically a tip of tree clang/llvm is all you generally need to build it
<heat57>
yeah but early magenta is already out of the build system
<geist>
yeah
<heat57>
and it's delightfully monolithic AND still lkuser-ish
<geist>
it wasn't until 2018 or so that it eventually got fully integrated
<geist>
the make stuff in zircon got initially replaced with it's own GN-based build system (different form the overall one) and then integrated into the overall build system
<geist>
which IMO was actually worse design than the zircon specific gn-based one
<geist>
now internally everyone basically agrees that the GN buidl system is not good and it's a mess, and there's some push to replace with bazel
<heat57>
build systems are bad
<geist>
not that make would have scaled to deal with what we ended up building with GN, but GN has it's own issues
<heat57>
for the kernel? it can scale fine
<geist>
mostly in its works-as-designed inflexibility in a lot of axis that caused us to build a lot of really wonky abstractions on top of it
<heat57>
yeah
<geist>
agreed re:kernel. but one of the things that was basucally a full-stop-no-exceptions rule with folks developing build systems around work is there shall only be one
<geist>
ie, no recursive building of multiple build systems. which i think is very silly, but thats what dogma gets you
<heat57>
yeah
<geist>
ie, all build systems must always be single instance
<geist>
tis why, for example, when we import a rust or any third party thing into fuchsia the build system for that thing must be rewritten as gn
<geist>
even rust. no cargo, etc etc
<heat57>
yeah
<nikolar>
getting away from cargo might not be the worse decision :P
<geist>
so now of course we have thousand and thousands of .gn projects that is going to take the heat death of the universe to replace
<heat57>
tbf i'm not sure how one can easily deal with recursive build systems and remaining build-systemy
<heat57>
as in having proper source deps etc
<heat57>
the answer is probably: tough shit, you can't
<geist>
you dont, you lose the flexibility of source level deps, but you get modularity
<geist>
it's how all large OS projects i've ever seen work
<Griwes>
I mean you deal with it Very Carefully
<geist>
like, debian doesn't build all of linux including the kernel, with one big ass make file
<geist>
it's not feasible
<geist>
or OSX, or windows, etc
<Griwes>
my current OS iteration barely has any components and the only sane way to build them that I found was to be very explicitly recursive from the top
<Griwes>
well, at least with currently available build systems
<Griwes>
I've been pondering one that doesn't have global compilers and whatnot, but rather objects representing toolchains that you pass to build targets to define them, but it has been a while since I've touched that
<geist>
yah for the lkuser stuff that i need to piddle with more i definitely am doing it as a recursive, at least in as much as external things are brought in
<bslsk05>
github.com: reaveros/cmake/target_functions.cmake at main · griwes/reaveros · GitHub
<heat57>
i think what i'll eventually end up doing might be to get some package manager to build individual packages + some cheap makefile to automate that for me
<heat57>
Griwes: yeah i know 0 cmake :^)
<Griwes>
that's _kinda_ what this entire cmake DSL is
<heat57>
apart from the little i needed to hack on LLVM
<nikolapdp>
package manager for what heat57
<heat57>
for packages
<Griwes>
it's likely that it'll evolve into a proper package manager _eventually_
<nikolapdp>
are we talking onyx userspace or what
<heat57>
userspace and kernel
Nixkernal has joined #osdev
<nikolar>
what packages would you have for the kernel lol
<heat57>
say if i adopted pacman, i'd use makepkg + pacman to build and install the kernel
<zid>
me and.. gog? were messing with something similar before
<gog>
hi
<zid>
and trying to decode the relocations, but for some reason they were stored -8 instead of -4 that the spec and all the tools claimed, or something
<zid>
does that ring a bell gog
PublicWiFi has quit [Ping timeout: 256 seconds]
<nikolapdp>
hello gog
voidah has quit [Ping timeout: 245 seconds]
<gog>
i only have relative and jump slot
<gog>
i think i'm using large model and that might be an issue i need to address because i don't need
<clever>
yeah, ive looked into that before, and the other models cause gcc to generate things like pc relative jumps with only a 24bit? offset
<zid>
does that ring a bell gog
<zid>
or was it someone else
<clever>
the root problem, is that only the linker knows the actual size of the offset
<heat57>
i feel like you're running without relocating your code
<clever>
and the linker cant change the opcodes, because gcc/as baked some pc-relative offsets within the generated code
<heat57>
but i dunno what you're doing exactly
<gog>
zid: i don't think it was me
<zid>
kk
<clever>
i think this is one area LTO can solve, but only for build-time links
<clever>
any dynamic linking is then left up for later, and i think you generally leave the full pointer width in the table?
<zid>
maybe it was froggey
<zid>
from a quick grep
<zid>
but doesn't feel right
<nikolapdp>
can you even disassemble the lto objects
<nikolapdp>
aren't they supposed to contain just the ir
<zid>
they're fat
<zid>
and contain both
<zid>
you need to use --with-lto=thin-lto or some crap to not have it do that
<heat57>
not by default
<heat57>
-ffat-lto-objects
<zid>
oh did they swap it most of my lto docs were from 6.0 tbh
<clever>
nikolapdp: i believe it contains both the normal .o contents (so a non lto link can proceed) and also the ir (so gcc can fuse the units together, re-optimize, and re-generate asm)
<heat57>
you need to ask for fat LTO by default i'm pretty sure
<zid>
the gcc 6 version of this or whatever says "We only support fat" or something :P
<clever>
so it generates things like this
<clever>
here, we have a pc-relative 27bit offset, and the mul2 just means bit0 of the offset doesnt exist, it must be 0
<zid>
GIMPLE bytecode could also be saved alongside final object code if the -ffat-lto-objects option is passed, or if no plugin support is detected for ar and nm when GCC is configured
<zid>
*or if no plugin support is detected*
<zid>
that might be relevent to some of my cases where it defaulted fat
<clever>
because the original as pass didnt fill in the addr, the offset is 0, and the bl is pointing to itself
<clever>
but with -r added, you can see what symbol it intended to call
<mjg>
wooo i'm telneting somewhere
<mjg>
talk shit all you want, telnet banner is great
<nikolapdp>
[Ayou can enable ssh banner too if you want in sshd_config
<clever>
repeated the test on aarch64, arm32, and thumb, with the default models
<clever>
loks like its a 26bit offset with aarch64, and arm32/thumb dont clearly specify the bit width
<clever>
arm also seems to be generating more prologue/epilogue then x86 did, the functions are a lot fatter overall
<clever>
but that might be differences in how gcc was configured, on x86 i used a linux hosted gcc, while on arm i used a -none one
<clever>
i saw something on the osdev wiki, about not using the hosted gcc for baremetal kernels?
xFCFFDFFFFEFFFAF has quit [Read error: Connection reset by peer]
<kof673>
i'm lost. build/host/target. build is what system you are building the compiler on, host is where the compiler runs surely? target is what it will generate code for
<zid>
means you need to pack your kernel build with a bunch of bizzare options to override every distro's random defaults, and the libgcc won't work after you do that
<zid>
and if a new option gets added your builds break
<nikolapdp>
that's why we have cross compilers
<nikolapdp>
and after geist merges my changes, i'd recommend his script to build them :)
<zid>
can I still use crossdev
<kof673>
^ and second ^ on x86 i used a linux hosted gcc, while on arm i used a -none one <<< that sounds like *target* to me, which *may* be the same as "host"
<nikolapdp>
sure zid, only you are allowed
<zid>
cool
<clever>
kof673: by hosted, i mean that gcc expects the target to have a linux kernel
<zid>
oh I should annoy my animals
<kof673>
that makes sense "by host i mean target" :D
<kof673>
not being sarcastic, makes sense
<clever>
and things like what zid said likely also apply
<clever>
i can see how redzone is fine in userland, but bad in kernel
<clever>
and a gcc targetting linux userland could have redzone enabled by default
<nikolar>
-mno-redzone
<nikolar>
ez
<zid>
nikolapdp: wanna watch me annoy the shit out of some animals?
rpnx_ has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<bslsk05>
wiki.osdev.org: GCC Canadian Cross - OSDev Wiki
<nikolapdp>
sure zid
<kof673>
i gave kazin his rush s3m, that is my canadian quota for the year
<GreaseMonkey>
tried playing around with protected mode in FreeDOS 1.3, turns out in the "seriously please don't load any drivers" mode it seems like it sets up a warm reboot handler for whenever you screw up and triple-fault the CPU
<GreaseMonkey>
i have mangled so many GDTs and caused so many triple faults... and haven't had to properly reboot the machine once
navi has quit [Quit: WeeChat 4.2.1]
<mjg>
i'm installing debian 3.0 (release 2005) in a vm, the installer is clunky af
<mjg>
worse than i remembered
<heat57>
why would you
<heat57>
ever
<heat57>
install debian
<mjg>
just wanna check something
<mjg>
it appears it hung doing mkfs though
<mjg>
i'm gonna try SLACKWARE instead
rpnx_ has quit [Ping timeout: 252 seconds]
<heat57>
does modern mkfs use O_DIRECT?
<mcrod>
i have learned not to try and install debian
<heat57>
i was thinking about blockers on an onyx installation process and if mkfs uses the page cache it might be one of the blockers to add proper reclamation
<heat57>
i was reading more about the ext4 journal just now
<mjg>
mofo took several minutes but got through it
<heat57>
really just stupid they didn't shard the journal per-block-group
<mjg>
unpacking debs is rolling fine, so i don't know what's that about
<heat57>
an fsync to a single file needs to commit the transaction FOR THE WHOLE DISK
<heat57>
inzane
<mjg>
oh yeah? do better
<heat57>
i believe the xfs journal is per-AG
<clever>
heat57: another factor, is that ext4 and zfs, handle the journal in vastly different ways
<nikolapdp>
true
<clever>
with ext4, i believe the journal is a sort of write ahead log, so you write important metadata to the journal, as a block#+contents pair
<clever>
and then overwrite the metadata in the proper location
<clever>
and if interrupted, the next boot can just copy it from the journal to finish the job
<clever>
but for zfs, the journal is instead a log of vfs actions, write/truncate/delete
<nikolapdp>
yeah because you can't really know everything in advance
<nikolapdp>
so you write the commands instead of the raw blocks
<clever>
yeah, its faster to log the commands, because it can be costly to know what the metadata should be
<nikolapdp>
yeah
<clever>
but, zfs can also reuse the backing data blocks, between the journal and the final data
<mjg>
lmao slackware is even worse
<clever>
so the data itself isnt copied, only the metadata
<clever>
also, each dataset in zfs (basically a filesystem) has its own journal
<mjg>
you have to run cfdisk by hand before you run the installer
<nikolapdp>
yeah zfs is pretty neat
<nikolapdp>
but i think you mistook xfs for zfs clever, lolo
<nikolapdp>
s/lolo/lol
<clever>
yep, i run zfs on nearly all of my machines
<nikolapdp>
i do too
<clever>
i'm not familiar with how xfs handles its journals
<mjg>
clever: on linux tho?
<nikolapdp>
ye
<clever>
mjg: yeah, all of my recent linux installs have zfs rootfs
<mjg>
wut
<mjg>
what's your take on btrfs
<nikolapdp>
i don't care
<mjg>
anyhow, the slackware installer printed that an error message from cat
<mjg>
and proceeed to claim the install is complete
<mjg>
gg
<clever>
mjg: i tried using it before zfs, deleting a large pile of temp files took 2 hours and then btrfs timed out and went read-only, lol
<mjg>
fucking WEBDEV
<clever>
i later discovered, a firmware flaw in my sata ssd's
<mjg>
clever: :p
<mjg>
when was that
<mjg>
oh so it's not even its fault
<clever>
under certain write patterns, the ssd just locks up solid
<nikolapdp>
lol i used an hdd with btrfs once, got corrupted literally the first time i tried doing something
<clever>
but i only discovered that flaw years later
<mjg>
zfs used to be notorious for getting into a spot where you can unlink a file
<mjg>
because there is not enough free space
<nikolar>
if you're worried about that, set a quote
<nikolar>
quota
<clever>
i think snapshots make that worse, but changing the slop space helps
<clever>
this reserves some chunk of the disk, like 30-40gig on some of my pools
<mjg>
and for some years now no longer does
<clever>
so zfs can write even when "full"
<clever>
changing that number can give you a ton more space
<mjg>
boils down to making sure the reserve is big enough to store that you unliked some shit
<nikolar>
yeah
<nikolar>
but not juts that
<nikolar>
you also need to free the snapshots that have that deleted thing
<clever>
with slop at 4, i have 0 bytes free, 5 gives 3.9gig free, and 6 gives 11gig free
m3a has joined #osdev
<clever>
nikolar: ive never had problems deleting things when full, but due to snapshots, deleting things when full does not actually free up space, so writes cant proceed
<nikolapdp>
yeah that's what i said
<clever>
also, running the free space down that low, has other more costly downsides, it fragments the free space something nasty