#Progress on NanoShell
1 messages · Page 2 of 1
long dash
i.e. –
ohhh i see
i think this is called en dash
yeah something like that
all of those replacement characters should be dashes?
or are there some different characters missing
I'll probably not go that far
isn't it the font's job to support it or am I missing something?
support what
the missing characters
and it does by placing a 0xFFFD glyph
i might add them though
i have to add each character manually
ohh I see
New widget, the combo box! This has been sorely missing for a while now.
I've changed the theming dialog to include this and will probably continue sprucing it up to allow making your own theme soon
yo this is fire
also, finally a preview of the theme you're selecting
if I fork nanoshell and make it have a kernel, will you consider that outrageous
is the buttons being on the left side a design choice or a temporary thing?
nah
?
it has a kernel already
if you wish to make it have a small kernel and everything on top in user mode, be my guest
nah, NanoShell64 is totally different
I meant this, usually they're on the right
so apps don't run in kernel anymore
It is intentional
👍
I wish you good luck if you really want to do it
eee wanted to port nanoshell to x86_64 at some point, but then changed his mind
so just warning you
Fair
this looks so cool
that would be funny since I'm already writing a 64-bit OS
back then, I was not
You could contribute to that instead. #1061224194450407435 for more info
working on a color picker widget
it makes interesting patterns when the sat is fucked up
Yesterday I did some heavy optimization to the way NanoShell GUI applications wait for events. Instead of waking up every time the WM updates (right now, only in the case of single window applications), they wake up when an event is received. So they often don't even run at all waiting for events.
as a result, the CPU usage is much smaller. While before, with the system monitor, cabinet and taskbar open, it was hovering around 15%-20%, now it's 5-10%, which is a big improvement:
My OS finally has a tmpfs. The /temp directory is entirely hosted inside RAM. It has all the features of the ext2 file system.
Next on the chopping block would be revamping the file picker (it dates to around april) and adding symbolic links
"/temp"
animal cruelty
sorry, */Temp
before you wonder "why the unstandard name?", well, everything is unstandard
is not "unstandard", is Nano standard or better a Nano-like OS

huh?
is not "unstandard", is Nano standard or better a Nano-like OS
huh?
anyways, yeah, as you can see, it works fine
it even tries to reveal what the file is; if it cannot do so, it shows a special icon
don't mind the mess of my Ext0 partition, but you can see, LinkTestLink is a link to a directory...
and I can enter it, no problem!
Yes
Yeah it doesn't conform to any standard
But I don't think anyone will try to clone my OS, so a "NanoShell-like" probably won't exist
finally using a slab allocator for my kernel heap, memory usage has dropped by a whopping three (!!) megabytes after just starting the WM
after browsing the ext2 file system for a bit but with a planned path with both the old allocator and the new slab allocator, the inode cache ended up growing the mem usage to:
- 6.5M for the old allocator
- 5.0M for the new allocator
that's some great improvements
good job! what style of allocator did you use before?
was it page frame?
it's still a page allocator that provides pages for the slabs
but i just use slabs for allocations less than 1024 bytes in size (not 2048, since my design isn't the best and I need to store metadata in the first few bytes of the page)
lmfao
Damn
Damn
I'm trying to port halfix, a simple x86 emulator in C99 that I recently heard about
goddamn
its super slow
and it crashed system monitor
use TinyEMU
(that's a "light" version of Windows XP which is a 44mb iso)
will try that soon
well as long as it doesnt require any complicated apis i'm down
like termios
can you swap off the frontend
not that I know
lmfao
eck yo
ayoooooooooooooo
I also tried booting an image of NT 4 but it gets stuck at "NTDETECT V4.0 Detecting Hardware..." with a bios message something like "int 13 parameters out of bounds 0000 0000 0001"
fyi this is apparently the bochs BIOS
damn that's cool
did you not try running nanoshell in nanoshell yet?
I tried it in halfix in a web browser and it triple faults printing the test pattern on the screen
I don't know why it crashes for me. I tried disabling fxsave (using regular fsave instead)
Icons on the desktop -- Need to evaluate the performance and optimize it but it seems to work for now.
there is a new desktop window that behaves as if it were the background, so now the background is drawn by the desktop window
if the desktop window is gone, poof, you have no background and there is no screen clearing
PNG support added: icons are loaded from actual PNGs now, and to celebrate this occasion, I've acquired a new wallpaper.
Thanks to @\qookei for the help implementing the PNG decoder.
Port of Super Mario 64 🤣
real
dang, not compiling with -fno-mmx -fno-sse did a world of difference
now it runs decently at 480p, and near flawlessly at 240p
ain't no fucking way
absolutely amazing dude
never heard of anyone porting mario 64 to their os until now
i doubt it is
still amazing
Well, I can go to jail for this, so...
i dont think nintendo would care if a hobby os ported super mario 64 to it
they are a huge company surely they wouldnt care about one person doing something very minor
We criminalized copyright infringement, it doesn't even matter of Nintendo cares.
I used the open source SM64 decompilation project.
So the only copyright infringement is me using the Mario 64 ROM to build it. The sources are available on github, but of course, without Nintendo's parts
Also who's "we"?
The country I live in.
Pretty much every developed country has
In most places, there's additional requirements for copyright infringement to be criminal, such as financial gain.
One more thing, if Nintendo really cared they would have taken down the actual decompilation of SM64.
Nintendo only really cares about things that happen here.

Super mario 64 for nanoshell has sold 5,0000,00 copies so far
I think they'll care tbh
real
is that GUI a separate ELF or is it built in?
Is this an OS for older pc’s or do you just like this ui style
Built in currently
I like this UI style
It's an OS for slightly older PCs too (early 2Ks)
Ah nice
yeah
Just pushed some bug fixes to NanoShell......... such stupid bugs
i demand a 1500 word postmortem detailing the exact failure causes
Sure.
https://github.com/iProgramMC/NanoShellOS/commit/8baca71656f6235214e54acb97badb40d2d6d462 "* Fs: Fix rename logic"
This one was STUPID, actually two bugs were fixed in this commit.
First off, I wasn't initializing pNameOld and pNameNew in all cases
inb4 I am stoopid 500 times over
The second bug also involved renaming, but in the ext2 driver, previously I was trying to add the new entry with an inode of 0 (perhaps originally it was in the order it is now, but I swapped them to reduce the amount of failure handling code)
the old code looked something like this
int Ext2RenameDirectoryEntry(Ext2FileSystem* pFS, Ext2InodeCacheUnit* pOldUnit, Ext2InodeCacheUnit* pNewUnit, const char* pOldName, const char* pNewName)
{
uint32_t inodeNo = 0;
uint8_t typeIndicator = 0;
int result;
// add the new entry.
result = Ext2AddDirectoryEntry(pFS, pNewUnit, pNewName, inodeNo, typeIndicator);
if (result < 0)
return result;
// remove the old entry. Make sure to not actually delete the inode.
return Ext2RemoveDirectoryEntry(pFS, pOldUnit, pOldName, true, true, false, 0, &inodeNo, &typeIndicator);
}```
as you can see, the inodeNo of 0 is used which is BAD
the fix was to swap them around and introduce failure cases in case Ext2AddDirectoryEntry couldn't add the entry for whatever reason
which is to just try to add the old one back, if that failed, then "oh dear"
next up we have https://github.com/iProgramMC/NanoShellOS/commit/6cc0c9404c30a7dac4a29193b42d25fc95b3a573 "* Ht: Fix terrible bugs in hash table implementation"
this fixes a memory leak and a stale pointer reference bug
my hash table implementation stores a list of buckets which are linked lists of elements
when removing, I wasn't updating the pFirst reference, so it was keeping a stale pointer as its pFirst
which is obviously very bad when an element that was already erased is being erased again (which this code don't expect)
so it was trying to pass NULL to the device write function
the memory leak was in the resize function, the code previously looked as follows:
this reallocates the bucket items when adding into the new hash table, so it puts whole new bucket items (pointing to the same data though) into the new hash table
but the old ones are not being freed
the fix was to perform the move manually
which looks like this
the last bug I fixed was that the taskbar's CPU/MEM graph and clock would freeze when you opened the taskbar settings menu from it. The fix was simple, in the window timer tick function, just return if the window is marked frozen
this prevents the window manager from trying to issue events to the window (which are going to be dropped because the window is marked frozen)
not sure why, but it wasn't sending events anymore
I wanna also update the fonts to be nicer to look at
both the current system font and "new font" (unused)
do you have a cross compiler for this OS?
like a custom compiler that compiles together the std lib for this specific OS
(for example i686-nanoshellos-gcc)
No
font update
i love the look of this
A slowdown of the stuff that goes on behind the scenes of the NanoShell window manager
Done using a slowed down QEMU (with -icount 3 iirc)
The most satisfying part is when a window is restored from maximization and everything else pops in bit by bit
what kind of optimizations NanoshellOS has? (graphics-wise). It seems like it has some kind of chunks rendering system?
Essentially, I use a mechanism to determine which rectangles to refresh the background from, respectively each window
It's basically a "cookie cutter" mechanism
You start with one rectangle from which you cut out other rectangles and their area won't be included anymore
Also, fast graphics routines
Helps that my video backend is essentially hardcoded to 32-bit color
My memcpy implementation is implemented like "read a bunch, write a bunch"-- all GP regs including EBP are used
Also all writes to the main frame buffer are mirrored to a region in RAM which is very useful to handle cursor drawing
it's nanoshell's second birthday tomorrow, so after I write the second year document, I might actually create a new FAT driver for the system
https://github.com/iProgramMC/NanoShellOS/blob/master/doc/happy_2nd.md Happy birthday, NanoShell!
Nice, congrats on the 2 years
Average stack overflow question be like
nice gui
Hey guys.
Today I announce that NanoShell will begin the process of migrating to MS-DOS.
With the stability of Windows 95, NanoShell/MS-DOS will finally be able to compete with the REAL operating systems, MS-DOS and OS/2.
Additionally, Microsoft Internet Exploder will be ported to NanoShell, coming out this Jule.
Welcome to the new NanoShell.
nanoshells kernel is going to suck a wiiiiittle bit less
i'm going to allow multiple dispatchers to the same IRQ number
boron actually supports this already by way of the interrupt object
background: I got this drive to actually make a networking stack for this OS, admittedly will be kinda shit
but boron's a little stuck on the boilerplate
and i don't wanna let this drive go to waste
sounds cool, keen to see your progress 😄
Just tested the OS a few days ago. It still runs on real hardware! It didn't run great here, but that's mostly because this computer isn't fast
It's a pentium D at 3.0ghz, with 1GB of DDR2
looooong ass time no see
i stumbled across a font design that i apparently scrapped or something
so i decided to try to make it usable
something like this might end up being the new font of nanoshell
also i was thinking of revamping the kernel task and mutex system. for the heck of it
could backport some stuff from boron
it suuuuuucks mad balls right now
especially the "SafeLock"
it's like a spinlock but bad
if it's not going to be the font for nanoshell it's definitely going to be the font for boron
oh a bit late, but happy 3rd birthday, nanoshell!
if you're wondering if my NES game (https://iprogramincpp.com/celestenes) runs on nanoshell, the answer is No
but that's a limitation of the emulator I ported rather than a limitation of nanoshell itself
I need to port a more competent emulator
the answer is now Yes!
I borrowed an NES emulator written in C, fixed a few bugs, and ported it to nanoshell
thats cool, hows the performance?
It actually seems to run okay in virtualbox
A bit stuttery but that's what you have to deal with when you have millisecond resolution timers and also the OS doesn't have any kind of priority management and timer stuff like Boron does
ah it was never going to be blazingly fast, it working at all (and being playable) is still cool
