<qookie>
well i was just porting it to aarch64 so the code to do that was already there :^)
gxt has quit [Ping timeout: 258 seconds]
FreeFull has quit []
gxt has joined #osdev
<geist>
for zircon we basically have a mechanism whereby early code can keep a list of reserved regions of physical memory, some of which comes from the bootloader in whatever mechanism it is, and some of it from the early boot code (page tables, etc). when the VM comes up, which is pretty early as the PMM arenas come online those pages get instantly knocked out and marked as wired so they're un allocatable
<geist>
so that by the time the VM is up and taken over memory allocations, there's no chance of accidentally allocating something with something important in it
<heat>
you know, i wonder how bootloaders are coping with the new accepted and unaccepted efi memory types
<heat>
i guess they'll just assume unaccepted = unusable
solenya has joined #osdev
<heat>
seems... sane
<clever>
heat: i think the osdev wiki says that efi applications can make up their own memory types, but some firmware wont allow it
<heat>
no, this is a new efi thing for TDX and SEV
<heat>
memory needs to be accepted before it's usable
<heat>
you accept it through $tdx_or_sev_mechanism
<heat>
so what happens is that you get a bunch of memory regions with an unaccepted memory type
<heat>
linux (or your favourite TDX/SEV aware kernel) will then accept them
<heat>
supposedly as needed
frkzoid has quit [Ping timeout: 244 seconds]
opal has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
opal has joined #osdev
gxt has joined #osdev
matt__ has joined #osdev
netbsduser has quit [Remote host closed the connection]
<bslsk05>
en.wikipedia.org: A Commentary on the UNIX Operating System - Wikipedia
<kazinsal>
Fourth Edition because it's the edition that was written in C, and because I'm poking at reimplementing it for IBM PC and XT class machines
<epony>
yeah, but why do you think it is a realistic objective for the XT
<kazinsal>
Because it's fun?
<epony>
no MMU
<epony>
how fun could it be
<kazinsal>
Neither did early PDP-11s that Unix could run on.
<epony>
something was missing, to have to use CP/M those days.. what could it be?
<kazinsal>
It's fun because it's a charming retro development challenge -- implement a vintage operating system on a vintage machine of known, relatively fixed, simple specifications.
<epony>
no disk?
<epony>
no protected mode?
<kazinsal>
First-generation XTs came with a 10 meg hard disk and 64-256K on the mainboard
<epony>
and in emulator everything can be a bit spruced up ;-)
<kazinsal>
Could, but that's not the point of the challenge
<epony>
well, let's find out the real limitation then
<kazinsal>
I think there will be a limitation when it comes to how sufficiently multi-user the system can be, but since my preferred cycle-accurate vintage PC emulator doesn't (yet) have support for attaching serial ports to other serial-equipped applications over eg. named pipes or TCP sockets, I'm not considering that a priority-1 issue at this time
<dh`>
shouldn't be a problem as long as the users aren't hostile
<epony>
a serial port data exchange is the first and only thing I would do there
<epony>
it's not even an 80286
<kazinsal>
I'm not concerned about lack of memory protection as that's also something we can consider a historical quirk of early Unix -- before memory protection was standard on PDP-11s for Unix installations, it was customary to inform people that you were about to load a new a.out you had just produced so they could save their work in case the machine dumped core
<epony>
and the other thing you would not have is multiple physical storage devices, serial ports and system console
<kazinsal>
You'd be surprised how many bizarre ISA cards were built...
<epony>
it's a severely limited machine, unlike the PDPs
<dh`>
erm
<kazinsal>
It may not have a front-panel to toggle bootstraps into but I am pretty sure you couldn't order an XT from IBM without at least one display adapter
<dh`>
the mainboard architecture gives you four serial ports and most machines came with two
<bslsk05>
en.wikipedia.org: Intel 80286 - Wikipedia
<kazinsal>
I think you are under the severe misunderstanding of the difference between multitasking and memory protection.
<epony>
the misunderstanding is somewhere else
<dh`>
64K is extremely tight for writing it in C rather than assembler, but 256K shouldn't be a problem
<kazinsal>
There were multiple commercial operating systems in the early 1980s released for 5150/5160s, so this is not some magical new impossible feat I am attempting
<dh`>
amigaos fit in 256K (though not that well) but it was far more substantial than v4
<epony>
you have the system books for the PC?
<kazinsal>
Of course
<epony>
I mean the hardcopies from that epoch.
<kazinsal>
I'd like to get my hands on hard copies but unfortunately I haven't managed to yet
<dh`>
I am pretty sure all the ones I might have had got thrown away
<epony>
I have them here, and have read them at the time when the XT was modern..
<dh`>
I have some stuff from that period (e.g. turbo pascal manuals) but I think I decided that 16-bit x86 was best burned
<kazinsal>
Quick perusal of PC Magazine from August 1982 -- a Unix-like system from Quantum Software Systems was available in a four simultaneous user configuration requiring 128K of RAM and a 5 meg Winchester disk
<epony>
that would be CP/M
<dh`>
multiuser cp/m?
<kazinsal>
QUNIX
<epony>
it needed the Z80 then on both 6502 and 8086
<dh`>
er wut
<kazinsal>
Pardon
<dh`>
ITYM "it only ran on Z80 then, not 6502 or 8086"
<epony>
it was also barely multi(two) process not multiuser
<kazinsal>
Ha! Okay, looks like Quantum QUNIX was renamed in 1984 to avoid being sued by Western Electric... to QNX
<dh`>
relatedly, are you planning to allow > 64K of either code or data in one process?
<kazinsal>
Pretty standard naive fork implementation based on the description in the manual. Unfortunately as far as I know complete source for v4 is lost
<kazinsal>
Not sure, but I'd likely need to adapt a.out for the DOS compact memory model, which could profe interesting
<kazinsal>
64K of code ought to be enough for anybody ;)
<epony>
segmentation and paging lived on for a while
<dh`>
the reason I bring this up is that forking without VM either requires that the two copies live at the same addresses (in which case you have to swap one out to run the other) or copying both code and data and applying relocations (a mess meaning you have to keep them somewhere), or a pic model that you aren't going to get in 16-bit x86
<dh`>
sticking to <= 64K will give you a pic model
<kazinsal>
Yeah, that's part of the trickiness of it all
<dh`>
also at this point it's difficult to get a toolchain suitable for this environment
solenya has quit [Ping timeout: 252 seconds]
<kazinsal>
That was definitely one of the hard parts of starting this up, yes. It took a while for me to figure out the quirks of Open Watcom's linker
<dh`>
can you get hold of a copy of Turbo C?
<epony>
one thing is certain, even if you did not achieve anything, you will definitely find out why the coprocessor was needed
<dh`>
huh?
<kazinsal>
Also Open Watcom has like, four different front-end drivers for the actual compiler, each of which has a different and incompatible syntax and feature set
[itchyjunk] has quit [Remote host closed the connection]
<dh`>
charming
solenya has joined #osdev
<kazinsal>
Weird things, too, like the front-end that's vaguely compatible with gcc invocation syntax specifically not being able to target the tiny memory model, but the front-end that's vaguely compatible with cl.exe's invocation syntax can
solenya has quit [Ping timeout: 260 seconds]
solenya has joined #osdev
skipwich has quit [Quit: DISCONNECT]
<dh`>
strange
<dh`>
I suppose it's the result of having different versions sold to different audiences that all got rolled into the free version
skipwich has joined #osdev
<dh`>
and never seriously maintained since I guess
lentement has quit [Remote host closed the connection]
<epony>
think of its "importance" and 'significance' accordingly
<bslsk05>
en.wikipedia.org: History of compiler construction - Wikipedia
zaquest has quit [Ping timeout: 248 seconds]
rpnx has quit [Ping timeout: 252 seconds]
eroux_ has quit [Ping timeout: 260 seconds]
rpnx has joined #osdev
cowboy8625 has joined #osdev
eroux has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
solenya has quit [Quit: WeeChat 3.6]
<cowboy8625>
is there a way to work on a part of the os with out having all the inisual bootloader and jazz?
<geist>
yeah, this is where i recommend using qemu and -kernel option, which skips most of that jazz
<geist>
but also depends a bit on which arch you're interested in
<geist>
though in general -kernel on most arches qemu just gets ya going and skips the jazz part
dasabhi has joined #osdev
<dasabhi>
hellooo
<dasabhi>
missed you guys
<geist>
'lo
<dasabhi>
have any of you guys built some type of edac system in your kernels
zaquest has joined #osdev
<geist>
what is edac?
<dasabhi>
error detection and correction
<epony>
the real question to be concerned with is, why in kernel space and not on HW
<dasabhi>
linux has a fany edac subsystem
<dasabhi>
well its for reporting
<dasabhi>
memory controllers implement the actual EDAC
<epony>
of the HW SECDED?
<geist>
that's not necessarily edac as much as a driver for the existing hardware
<epony>
now, make a parallel now with FS variants of that..
<dasabhi>
but kernel space actually gets the error info on the memory module
<dasabhi>
yes a driver, has any one needed to build such a system
<epony>
the FS ECC is in kernel space
<klange>
I don't think I've even had the opportunity to _see_ ECC RAM.
<epony>
I have ECC RAM in my desktop..
<epony>
there are rare versions of laptops with it too, but it makes no sense there
<epony>
desktop as in "tower" in the WS class
<moon-child>
isn't qemu -kernel just multiboot?
<dasabhi>
yeah that makes sense, most desktop machines dont have ecc memory
<moon-child>
doesn't seem like you get to skip very much vs just using grub. A bit of disc setup ceremony, and that's it
<epony>
AMD CPUs support that on the dual core and later gen consumer CPUs
<epony>
Intel only on the Xeon lines
<moon-child>
klange: it just looks like ram :P
<dasabhi>
either ways, just wondering when writting a device driver, should the probe functions we register be written in some type of loop?
<dasabhi>
first time modifying a device driver for myself
wxwisiasdf has joined #osdev
<wxwisiasdf>
Hello people
<dasabhi>
and the sample device drivers i read up on in linux land, did a few setups and ended their probe commands
<klange>
moon-child: x86 -kernel is multiboot, but missing some modesetting functionality that I keep thinking I could add and the QEMU dev people have said would be accepted if someone bothered to write it, but...
<cowboy8625>
thanks @geist
<klange>
It's good for not having to set up a GRUB disk, which has historically been at least somewhat annoying (and still kind of is grub still gets packaged in a way that makes the tools awkwardly dependent on the host system's own grub configuration)
<epony>
in you're not working on crytpography research, do not run long running important programs like emulators and virtual machines, or language and application servers, or shared resource servers, and if you reboot or otherwise interrupt your workload frequently, you have no use of ECC RAM in particular in HW, and can deal with "application" level validation of data paths and files out-of-order
<klange>
what are we calling "long running"
<epony>
open for individual selection probably (arbitrary by importance or consumers)
<epony>
ot
<epony>
it's olways good to have but it's a bit slower
<epony>
there are multiple variants of the HW implementation and memory module types that support that feature "set"
<epony>
exist and are in use since at least mid-90ies
<epony>
operating systems and applications that do excessive or critical evaluation of memory regions and usage will be benefitting from this moreso, than naive implementations that do not move data in memory much, or not check its validity, and that is significant improvement in reliability there, despite being a combined "slower" end result
xenos1984 has quit [Quit: Leaving.]
lentement has joined #osdev
<mxshift>
dasabhi: yes, I've worked on multiple systems. Linux edac, Google's mcelog, illumos FMA, and various RTOS implementations
lentement has quit [Remote host closed the connection]
lentement has joined #osdev
<geist>
klange: agreed. ocne you figure grub out it's not too bad, but it requires fiddling with more than one host os specific tools, etc and then that can turn into it's own set of dependencies that's hard to support
<dasabhi>
mxshift: googles mcelog? i thought mcelog was just used in bsd
<dasabhi>
mxshift: wouldnt google use linxu edac
<dasabhi>
mxshift: have you ever written custom edacs?
<dasabhi>
mxshift: for a specific memory controler ?
<mxshift>
No. Google data center servers primarily do error detection in user space. mcelog was written specifically to allow recording of ECC events so they could be decoded later
<mxshift>
Yes. Working with folks on EPYC 3rd gen for illumos FMA currently
lentement has quit [Remote host closed the connection]
<dasabhi>
mxshift: illumos, does any one actually use that?
air has quit [Read error: Connection reset by peer]
gog has quit [Ping timeout: 240 seconds]
GeDaMo has joined #osdev
foudfou_ has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
dude12312414 has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
[itchyjunk] has joined #osdev
potash has quit [Remote host closed the connection]
tarel2 has joined #osdev
potash has joined #osdev
davros1 has joined #osdev
<davros1>
Regarding the effort to reverse engineer apple's M1 GPU (for linux support) - could that yield a 3rd party native Vulcan/OpenGL driver for M1/Mac OSX, or does the mechanism for triggering GPU work require official OS support
<davros1>
in modern graphics APIs you build command lists in user program space, right?
<epony>
oh look at that ;-)
<davros1>
lo
<davros1>
lol
<j`ey>
davros1: the GPU side has been tested by running opengl on macos
<davros1>
Ok thats encouraging
<davros1>
Either goal is of interest to me. One of my reservations about Apple is that they deprecated OpenGL and dont support Vulkan (and doing vulkantranslated to metal seems awkward to me)
<davros1>
Similarly I just prefer linux as a programming environment
<davros1>
But the M1 hardware is so appealing to me
<vdamewood>
It's so shiny
<davros1>
I miss having a computer where I dont think the ISA is disgusting
<vdamewood>
davros1: Been stuck on x86?
<davros1>
I have ARM toys and x86 main machines. I bought an M1 mini to debug something, intending to leave it in the corner . Then this UK energy crisis hit and I thought "hang on, 7w idle makes it a perfect daily driver"
<davros1>
Now my predicament is that I regret not getting the Mac studio and am still considering upgrading
<davros1>
But for reasons expressed I have reservations about apple. Either linux/m1 or OpenGL+Vulkan /macOSX fixes them
<j`ey>
davros1: get the studio, try out linux on the mini until it works well enough for you, then switc on the studio ;)
<davros1>
Yeah thats exactly one scenario I am considering
<davros1>
I would not install linux on "My only Mac"
<vdamewood>
I'm happy with macOS myself, but I'd love to run Linux in a few virtual machines.
<j`ey>
davros1: I mean it dual boots by default anyway
<vdamewood>
In fact, that's what I have no, but i'm on an Intel Mac.
<vdamewood>
have now*
<davros1>
Yeah I'm still just nervous installing something
<davros1>
But with a spare I could be more adventurous
<tarel2>
as Linux user Vdamewood what do you like about mac?
<vdamewood>
tarel2: Originally, the fact that I had a Shiny GUI with a nice, FreeBSD-based Unix system in the terminal.
<davros1>
Heh. I like the fact everything is top-menu by default
lukflug has joined #osdev
<vdamewood>
davros1: Infinite edge UI design?
<vdamewood>
tarel2: These days, I also like the fact that my computer integrates with my TV and my Phone.
<davros1>
Fitts law
<vdamewood>
Same thing. The edge is infinitely large.
<tarel2>
I can did that vdam
<tarel2>
dig my bad
<tarel2>
my os works with my phone too , both are Linux
<davros1>
Synergy of fitts law and keeping the menu out of each window where it wastes space and is often truncated anyway
<davros1>
Yeah just checking thats what you meant by infinite edge
<GeDaMo>
What are the five points easiest to click with the mouse? :P
<vdamewood>
davros1: One of the things I like abut macOS is how much more intuitive the equivalent of MDI is on macOS. Instead of having a Window within a Window, the containing Window is the desktop itself, so your windows are just windows.
<vdamewood>
GeDaMo: Where the mouse is, and each of the corners.
<vdamewood>
screen corners
* GeDaMo
gives vdamewood a coconut
<vdamewood>
Yay!
* vdamewood
drills open the coconut and drunks the milk.
<vdamewood>
drinks*
<davros1>
Gnome shell has utterly retarded waste of top screenspace
sikkiladho has quit [Quit: Connection closed for inactivity]
<davros1>
When the linux world tries it usually gets UI wrong
<davros1>
But 2nd best use of the fits law space is putting the dock there, which plenty of linux DE's can do. But the best use is the application menu.
<tarel2>
gnome is one I had because it was just there at the time ,but when I do pick I like KDE
<vdamewood>
At least KDE still has the Application menu in a corner.
<vdamewood>
GNOME 2 was so much better, especially since in a lot of wasy their take on UI design was 'copy Apple'
<davros1>
Corners can be lost in a multi monitor setup , but top menu still works with monitors side by side
<tarel2>
Xfce , is what i have on the pi
<davros1>
Yeah xfce is my favourite linux de
<tarel2>
it does not take much right?
<tarel2>
I guess I like xfce for the simple reason , its easy to understand. so if need gui I don't need something big like KDE or gnome
<davros1>
Yeah its just right, its not super minimal like the tilers , but doesn't try to do too much, which linux DE's always get wrong
<davros1>
So what's the deal with opensoruce OpenGL on the M1 .. how does a GPU command list get executed
<davros1>
In a past life I did console dev where we had documented registers for that sort of thing
<davros1>
"Build command lists in memory and point hardware at it, write here and it goes"
<demindiro>
virtio-gpu & it's "hardware" cursor confuses me, it appears it moves the cursor relative to my monitor instead of the QEMU window.
<demindiro>
Moving it also causes the PS/2 mouse to generate an event so the cursor gets stuck in a corner
dude12312414 has joined #osdev
Piraty has quit [Quit: -]
dude12312414 has quit [Remote host closed the connection]
<demindiro>
It appears Linux does something special with the PS/2 mouse, which is why it works
xenos1984 has quit [Quit: Leaving.]
bauen1 has quit [Ping timeout: 268 seconds]
Piraty has joined #osdev
Alexthek1d has quit [Quit: Leaving]
smach has quit [Quit: No Ping reply in 180 seconds.]
smach has joined #osdev
matt__ has joined #osdev
oldtopman has joined #osdev
<demindiro>
So it appears the mouse pretends to be PS/2 but it's actually a vmmouse that works with hypercall magic
<demindiro>
Fun
isaacwoods has joined #osdev
demindiro has quit [Quit: Client closed]
xenos1984 has joined #osdev
elastic_dog has quit [Ping timeout: 268 seconds]
demindiro has joined #osdev
demindiro has quit [Client Quit]
elastic_dog has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
foudfou has quit [Quit: Bye]
dude12312414 has joined #osdev
foudfou has joined #osdev
dude12312414 has quit [Client Quit]
wxwisiasdf has joined #osdev
<wxwisiasdf>
Hi, good morning people on developable systems that could be operated in systems developable irc chat
lukflug has quit [Ping timeout: 264 seconds]
xenos1984 has quit [Ping timeout: 268 seconds]
foudfou has quit [Ping timeout: 258 seconds]
foudfou_ has joined #osdev
wxwisiasdf has quit [Ping timeout: 244 seconds]
bauen1 has joined #osdev
xenos1984 has joined #osdev
FreeFull has joined #osdev
<sham1>
Hello verbose person
<geist>
Hoy
gog has joined #osdev
lukflug has joined #osdev
diamondbond has joined #osdev
epony has quit [Quit: QUIT]
matt__ is now known as freakazoid333
diamondbond has quit [Quit: Leaving]
epony has joined #osdev
terminalpusher has joined #osdev
<kazinsal>
dammit. finally out of the good coffee... now I need someone local to me to take a vacation to maui and bring me back a few more pounds of it
wxwisiasdf has joined #osdev
frkzoid has joined #osdev
freakazoid333 has quit [Ping timeout: 248 seconds]
<heat>
if you tell me "UCS-2 strings" I will fucking flip
<heat>
I will find you, and I will kill you
<wxwisiasdf>
ucs2 strings
<heat>
ahhhhhhhhhhhhhhhhhhhhhhhhhhhh
<heat>
are you macroing all your function calls with *A and *W variants too
<wxwisiasdf>
no
<wxwisiasdf>
we use constexpr for that
<heat>
cringe
<heat>
use LPCTSTR
<heat>
the long pointer *matters*
<wxwisiasdf>
but, but we are not windows
kklimonda has joined #osdev
<heat>
yes we are
<heat>
that is exactly what we are
<heat>
what else would we be
<wxwisiasdf>
:(
<heat>
uefi? even uefi doesn't have all these shenanigans
<wxwisiasdf>
no
<wxwisiasdf>
bios, grub2, protected mode
<heat>
in fact your EFI firmware has both ANSI strings and UCS-2 strings
<heat>
consistency is overrated
<heat>
but srsly though why do you need ucs2 strings and why can't you just use L
<wxwisiasdf>
okey i don't seriously use UCS2
<wxwisiasdf>
i only go as far w EBCDIC 1047
<heat>
you can ebc my dic any time
<wxwisiasdf>
hehe
<gog>
-fshort-wchar you rubes
<wxwisiasdf>
& wouldn't use UCS2 anyways since character constants are supposed to be character wide
<wxwisiasdf>
and some C standard violations would occour, and then the entire shit becomes ub
<heat>
no
<wxwisiasdf>
or were they int wide?
<gog>
nah UCS2 is 16 bits
<gog>
fixed
<heat>
fshort-wchar + L will give you a short-sized wchar_t
<wxwisiasdf>
hmm
<heat>
but that has nothing to do with normal chars
<heat>
it will not affect them in any way, as is sane
<wxwisiasdf>
well
<wxwisiasdf>
-fexec-charset=UCS2 makes character constants become multibyte
<gog>
yes that's what i'm saying
<heat>
that seems incompatible with real life
<heat>
your char cant both be 1-sized and short-sized
<heat>
(in normal platforms)
<wxwisiasdf>
gcc allows it, hence my previous "i wouldn't use it" statment
<wxwisiasdf>
it also allows UTF32
<heat>
it does????
<wxwisiasdf>
yes
<heat>
wtf happens to sizeof()?
<wxwisiasdf>
goes wild
<wxwisiasdf>
entire shit goes UB
<gog>
fucking
<gog>
this is language abuse
nyah has quit [Ping timeout: 268 seconds]
<heat>
lets delete gcc and use msvc
<heat>
sounds good yes??
<wxwisiasdf>
PE kernel time
<gog>
PE is easier to reloc anyway
<wxwisiasdf>
really?
<heat>
you're joking but PE kernel sounds easy
<heat>
you just need to objcopy it to something saner
<heat>
wxwisiasdf, no
<wxwisiasdf>
lol
<wxwisiasdf>
ah okay
<heat>
PE is batshit crazy
<gog>
:P
selene_ has joined #osdev
<wxwisiasdf>
why does windows always have the crazy formats
<heat>
uefi's PE loader is super unmaintainable and horrible and fugly and buggy and exploitable
<gog>
backwards compatibility
<heat>
thank fuck you didn't go forwards with the gsoc
selene_ has quit [Client Quit]
<gog>
yeah i'd probably be a wreck rn trying to finish it :P
<heat>
tbf it would be crazy useful
<heat>
but probably not in the state PE support is in right now
<gog>
yeh but i made way more money being a phone bitch
<heat>
but fun :(
<froggey>
qookie: maybe... yeah. hmm, I'm using the physical timer registers, maybe I should be using the virtual ones
<gog>
anyhow though, PE is just an extended COFF with a dos MZ stub saying "you can't use this .exe in DOS"
<wxwisiasdf>
hehe
<heat>
because dos is relevant
<gog>
that's why it's crazy
<gog>
that's also why DLL's are prelinked
<gog>
"dynamic" linking
<heat>
are they?
<heat>
what happens if two dlls conflict?
<gog>
relocations
<heat>
oh ok
<heat>
that doesn't seem horrible then
<gog>
it's got benefits and drawbacks
<heat>
prelinking to save up on startup time isn't horrible
<kazinsal>
yeah they're still relocatable, they just all get pre-linked to a "preferred" address
<gog>
yeah
<heat>
although aslr
<kazinsal>
in some big fancy applications this is REALLY cool because you can predefine your preferred addresses and just touch your modules without needing to ask Windows to get you a handle to one of your modules
<kazinsal>
we used this to great advantage in the Freelancer modding community because all the various DLLs making up the game engine always loaded at the same preferred addresses
<froggey>
oh, that seems to work
gxt has quit [Read error: Connection reset by peer]
<wxwisiasdf>
does the kernel itself load the DLLs? or is it like linux where an ld.so takes care of the dynamicity?
gxt has joined #osdev
<kazinsal>
it's handled by kernel32.dll which is the user-mode interface to the kernel
<kazinsal>
so it maaay make native kernel API calls but it may also do it in userspace wherever possible
<wxwisiasdf>
hmm
<kazinsal>
just grabbed my copy of windows internals, the image loader is in userspace
<heat>
kazinsal, how is kernel32.dll loaded?
<kazinsal>
kernel32 is just the implementation of win32 interfaces to system calls
<heat>
it's like microkernels' program loader problem, but everything is confusing and 10x more complicated
<kazinsal>
ntdll is the user mode native API to system calls
<heat>
yes but who loads that if the loader is in userspace
<kazinsal>
there's an initial loader that basically brings up the windows equivalent of init
<kazinsal>
and that's load-time dynamically linked against ntdll
<kazinsal>
so ntdll is always present
<kazinsal>
when it does its own first CreateProcess call the ntdll loader is used and basically references itself for the new process's load-time dynamic linking to ntdll
<kazinsal>
it's fucking wacky and wonderful
<gog>
i love microkernels
<kazinsal>
like if every process got a free reference to ld.so just for existing
<gog>
wouldnð
<gog>
wouldn't that make it like a vdso
<kazinsal>
kinda yeah
foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
<kazinsal>
if you have the money (or the expense account) I recommend picking up hard copies of Windows Internals 7th Edition
<netbsduser>
i've read excerpts of the older edition (the one covering Win2k)
<netbsduser>
very useful
<kazinsal>
I think they're on sale right now because back to school
<kazinsal>
totally worth owning so you can walk over to your bookshelf during a meeting where some contractor is arguing about shit he doesn't really know about and drop down 2500 pages of paperback and go "NOW LISTEN HERE YOU LITTLE SHIT"
terminalpusher has quit [Remote host closed the connection]
<moon-child>
soo
<moon-child>
did we ever get an answer on 'why ucs2'?
<moon-child>
because ... ...
<gog>
why not
<gog>
¯\_(ツ)_/¯
<kazinsal>
because NT develpoment started in 1989 and UTF-16 was defined in 1996
<moon-child>
I mean, why wxwisiasdf wants it when they are presumably not developing windows nt
<klange>
There's only three reasons to intentionally choose to use UCS-2: Laziness, a mistaken belief that the only things beyond the BMP are emoji and hating emoji, and racism.
<wxwisiasdf>
wha
<zid>
ucs2 is the ebcdic of 2020
<zid>
something you have to write programs around its existance but really don't wanna actually use for anything