My second computer (486) had that BIOS. I thought all computers would have that onwards. I had to wait until UEFI to see something like it again

hehe

that screenshot was taken using PCem

ARC firmwares had a similar kind of interface 🙂

it was basically a predecessor of EFI

its possible feed the UEFI-RS for when any program calls graphics or TCP already are there initializations and connections working. and if one area of the program creates a memory pool, there may be a translation layer connected both to TCP/IP and the MMap taking NDis driver as input and that is how a wlan EFI program is made + may be other processes called rings using MMap (Unix library NTDLL emulation)

even better. make uefi-rs with Unix lib emulating .exe/.dll directly over bare UEFI and you make an executable (ntoskrnl.efi->manager.exe) that manages threads and does the process i said above by calling uefi-rs. and poom, uefi desktop with aero shell

basically, you'd compile your efi program. output_files: ntoskrnl.exe ntfs.sys translayer.dll. my dreams are beyond quibble or reactOS

Is fireside gone?

the off-topic group

Damn, without Charles?

Ohhh lmao

why no one is using UEFI table for networking programs? except for Intel BITS

and for who would this be interesting?

for intel, and small systems like KolibriOS

probably because it is hardly documented, and probably less reliable than interfacing directly with known network cards?

one can program it using EFI Interrupts in some language functions, or EFI SDK

in assembly?

yeah, no, i think " When constructing a socket for the first time, _socket will initialize the EFI network stack, which will typically use DHCP to obtain an address " is CTypes backend

"Building on this networking support, BITS now supports the Python urllib2 module and its dependencies, to function as a simple HTTP client." heck, only to port SSL and any HTML/CSS interpreter

ok so you are just babbling theoretical here

till now, there's no web client ported to EDK2

ok so you are just babbling theoretical here

nobody wants to write actual code...

linux xd

port everything to EDK2, port netsurf, NDIS wrapper, Nouveau drivers, Unix library+NTDLL

port everything to EDK2, port netsurf, NDIS wrapper, Nouveau drivers, Unix library+NTDLL

EDK2 is shit

No multithreading

Like 64bit DOS

Plain memory model, no proper paging as well

you can build a .exe file that manages threads and is booted by Quibble

you can build a .exe file that manages threads and is booted by Quibble

I wrote many drivers for uefi, along with porting coreboot.

EDK2 is abomination. Overall idea of protocols is good, but have you ever tried to read the code of tianocore or AMI bios?

Try to see how USB driver is implemented in AMI for example

Operating systems are 1000 times better at writing proper drivers and bus/network stack

Operating systems are 1000 times better at writing proper drivers and bus/network stack

but then i want at least kolibriOS being small

Operating systems are 1000 times better at writing proper drivers and bus/network stack

This is also why eventually Fastboot mode was introduced, so unnecessary drivers will not take time loading but effectively being unused.

Because there is no multithreading in EFI, it can't initialize hardware in parallel, improving booting time. Linux for example, does this.

Using Linux+kexec might be a Better alternative compared to UEFI

Even Java/JS is a better alternative to UEFI.

Even Java/JS is a better alternative to UEFI.

Using Linux+kexec might be a Better alternative compared to UEFI

OpenPower servers use exactly this. They use Linux as a bootloader

I know, the only issue (IMO) is that Linux is huge, therefore it might have vulnerabilities that are difficult to fix.

I know, the only issue (IMO) is that Linux is huge, therefore it might have vulnerabilities that are difficult to fix.

Yeah, I prefer lean solutions as well. Just properly designed ones.

TempleOS?

Yeah, I prefer lean solutions as well. Just properly designed ones.

A rump-like unikernel?

UEFI is far from lean btw. *Stares at the 32Mb binary dumped from the laptop*

(using NetBSD's drivers)

Guys, let's stop offtopic please

A rump-like unikernel?

Interesting idea.

Samsung USB-C SSD☺️💪🏻

Samsung USB-C SSD☺️💪🏻

Does ROS have USB-C supports atm?

That is a connector

So if the machine reactos is installed on has a USB-C connector then yes

Does the hdd work? That depends on the USB 2 and 3 support that we have

Does the hdd work? That depends on the USB 2 and 3 support that we have

SSD instead of mechanic And MUST work on Linux But unsure for ROS

Does ROS have USB-C supports atm?

I think they work only with XHCI controllers

So OS should support them

👍🏻😊

I am not sure if "raw" SSDs will work though, e.g. NVME

Will ROS introduce dd command from BSD/Linux, where the same task needs complications on Windows?

Probably not, no.

dd itself could be ported easily but it also probably won't do what you're really thinking

dd only works on files, used for transforming them. So if you want to convert between ASCII and EBCDIC or change the byte endian of some files, a straight port would work fine. However I suspect you subscribe to the myth that it's a disk utility. Since Windows NT doesn't represent disks as files, dd still wouldn't work in that capacity.

Yes

i noticed KolibriOS has KWine. they want to feed runtime libraries through a header called kernel32.dll. thats the smartest bet never ocurred

What?

they probably forked Wine 🍷

but that's a wild guess, I didn't googled

I'm not interested much in other OSes than ReactOS 🙂

Not even Windows?

Not even Windows?

I mean operating systems unrelated to NT

NT is crap, honestly. you have already microkernels with asynchronous I/O, as NT4 was

unless you are sticked with reverse engineering, zCore may gain tiny framework implementations, like 100KB length. as well as Wine NTDLL runtime yeah! native, faster, cleaner, modern

NT is crap, honestly. you have already microkernels with asynchronous I/O, as NT4 was

Managarm looks interesting

yeah, there's mr. bonkers

in discord