DEV Community: Paull Knya-z

Я: не создатель, а управляющий

Paull Knya-z — Tue, 23 Jun 2026 07:41:51 +0000

Этот пост может вызвать разное мнение: кто-то скажет, что это честно, а кто-то, что это обман и неправильно.

Когда я начал создавать paull-kernel, я не задумывался о том, что этот проект позднее станет моим главным делом. Он задумывался как просто проект, чтобы написать ос. Ни зачем. Просто. Но когда проект стал больше, появилась его философия (дать рабочий фундамент студентам, чтобы они не начинали каждый раз сначала) то я понял, что эта статья обязательна. И в ней я расскажу о том, кто реально писал paull-kernel.

Тянуть не буду: скажу сразу. Весь код paull-kernel написан ИИ. Вот так, никто не думал. Но это не повод ругать меня, или ругать мой код. Во-первых:

это первая ОС написанная целиком ИИ: кстати, вторая философия моего проекта: показать на что способен ИИ.
я поддерживал код, писал статьи (первые тоже писал ии,но остальные мои, и все факты из них - абсолютная правда)
многие мои проекты специально созданы, чтобы показать на что способен ИИ.

Надеюсь теперь понятно, что я, скорее, управляющий. Я создал идея, поддерживаю код и пишу статьи. А код написан нейросетью. И это не плохо, это современный инструмент. Так что я полностью поддерживаю хороший код. Не ии-слоп, а хороший, работающий код.

Happy (AI) codding!

Моя 11 летняя дочь Эмма: как ИИ-поисковик придумывал мне родственников

Paull Knya-z — Mon, 22 Jun 2026 04:17:51 +0000

Недавно, проверяя свой профиль на индексацию последней моей статьи нашел я интересный факт: ии настойчиво утверждает о том, что в моей статье "Booting from FAT12..." В конце идёт речь о том, что ко мне подошла моя дочь и спросила "правда что раньше все писали сами? Откуда они знали,что писать?"

Я был чрезвычайно удивлен: я перезашел в гугл, включил ИИ-поисковик и о чудо! Опять моя "дочь". Поисковик невероятно хотел принимать мне родню. Я начал спрашивать, откуда это? Но ИИ отвечал что это все же из статьи "Booting from FAT12.." (к слову, ранние мои статьи писала нейросеть,но каждый факт абсолютно реален,просто у меня не было времени писать сложные долгие статьи,нужно было продвигать ос дальше,и мы разделились)поэтому я мог легко пропустить данный факт, но это было странно: я иногда перечитывал статьи, и сразу бы заметил ошибку.

Как вы видите, никакой Эммы нет. Не поисковик продолжал вешать мне лапшу на уши: он в конце, он в конце... Наконец я попросил его точно сказать откуда эта информация, и, как не странно, она из блога Бена Халперна. Мой профиль он просто случайно перепутал!
Вот та самая статья:

В итоге я нашел ошибку, но даже сейчас вы можете попросить ИИ-поисковик рассказать о моей семье, и он навешает вам лапшу на уши. Будьте осторожны при поиске с ИИ! Оно иногда путается в фактах.

happy codding

Напиши мне ИИ: новичок который хочет быстро найти обходные пути

Paull Knya-z — Sun, 21 Jun 2026 13:14:42 +0000

Недавно ко мне обратился новичок, который хочет быстро заработать 3.5 миллиона за то, что я напишу ему ИИ. Всего-то!

Он обещал мне какие-то золотые горы за мой труд? Он хочет чтобы я написал с нуля ему ИИ? Надеюсь вы понимаете насколько это сложно, тем более соло, за его "спасибо".

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

<...>

Собеседник: у меня крутая идея,мне она принесет 5 миллионов. Тебе нужно просто написать код для моего тг бота ии. Часть денег тебе

Paullknya: в чем проблема, пиши

Собеседник: так я ещё ничего не умею. Я новичок

Paullknya: тогда скачай vs code, и напиши свой первый hello world. А уже потом делай ИИ.

Собеседник: ОНА ПРИНЕСЕТ МНЕ 5 МИЛЛИОНОВ

Paullknya: Так, мне надоело это объяснять. Ты меня не слышишь. Хочешь делать — иди и делай. Но пойми: люди тратят годы на освоение программирования. А ты хочешь освоить науку за месяц? Это жалко. Твоя стратегия — найти исполнителя для твоей «гениальной идеи».

Собеседник: ты так считаешь? Мне сказали: «имба идея».

Paullknya: как ты не можешь понять,что это он делается за 2 дня? Это задача для больших корпораци.

Собеседник: Там можно собирать плюсы и просмотры

Paullknya:
Слушай внимательно.
Если ты реально хочешь что-то сделать — я не против твоих попыток. Но пойми несколько вещей:

Это математическое понятие. Без глубокого понимания математики ты ничего не сделаешь.
Это невероятно дорого. Подобные проекты не делаются в одиночку; это работа для крупных команд.
Этика и закон. Нигде нет готового «исходного кода ИИ» для кражи. Кража кода — это уголовная ответственность за нарушение авторских прав.
Я не участвую в сомнительных схемах. Если твоя цель — сделать бота для спама или обмана людей, я в этом участвовать не буду.

Paullknya:
Пойми главное: новичок должен учиться у профи. Я знаю, как это работает и сколько на это тратится ресурсов. Хватит витать в облаках: сделай достойный проект, который оценит сообщество.

Я прекращаю этот диалог только потому, что ты ищешь обходные пути там, где их нет.

Я сам против конфликтов, но тут исключительный случай: человек не понимает что это сложно. Мне пришлось перейти на личности и объяснить, что он просит невозможного. Мне очень жаль, но я считаю что я прав. Я надеюсь что вы со мной согласны.

Мой вывод: избегайте манипуляторов, которым плевать на ваш труд. Им нужны только их иллюзорные "3.5 миллиона". Не слушайте их. Вы потратите кучу сил на человека, который ничего вам не даст.

Happy codding!

How my OS is indexing by Google?

Paull Knya-z — Sun, 31 May 2026 16:24:51 +0000

I'm building a hobby operating system: Snorkel-OS (based on Paull-kernel), a 32-bit x86 kernel written in NASM and C.

For a long time, Google ignored my project. But recently, something changed.

What's indexed now?

My GitHub profile and the Paull-kernel repository.
A description that says: "32-bit kernel with protected mode, rings 0/3, system calls, command line".
My articles on Dev.to.

What's still not working?

Searching for Snorkel-OS shows an AI framework, not my OS.
Habr rejected my article (said it looks like AI‑generated – but I wrote it myself).

Next steps

Improve SEO: add proper meta tags, cross‑links between Paull-kernel and Snorkel-OS.
Keep writing technical posts.

Happy coding! 🐟

My OS has a new name: meet Snorkel‑OS

Paull Knya-z — Sat, 23 May 2026 14:28:41 +0000

Snorkel‑OS – unusual, isn't it? Let me explain.

A snorkel is a tube that lets a diver breathe while staying just below the surface, observing the underwater world without interruption. For me, a computer is a similar “parallel world” full of mysteries. My operating system is a view from the outside, but as close as possible to the hardware and the code. I renamed the project to emphasise this metaphor.

Technically, the kernel is still called Paull‑kernel (a 32‑bit x86 monolithic kernel written in NASM and C). But the whole operating system is now named Snorkel‑OS.

The kernel is what's inside. The OS is how we see it from the outside.

My next technical article (about the FAT12 file system) is coming soon. For now, just remember the new name.

my OS link: https://github.com/Paullknya/Paull-kernel

forum(mailing list): https://paullknya.github.io/

Happy coding! 🐟

Booting from FAT12: How I added file reading to my x86 kernel

Paull Knya-z — Fri, 22 May 2026 14:23:41 +0000

My kernel Paull-kernel (32‑bit x86, protected mode) already had a command line and could run built‑in commands like hew → hello world. But everything was hardcoded. To load and run external programs, I needed a real file system.

I chose FAT12 – the classic floppy disk file system. Simple, well documented, and perfect for a hobby OS.

🧱 FAT12 structure (short version)

A FAT12 disk looks like this:

Boot Sector (512 bytes) – contains the BIOS Parameter Block (BPB) with geometry info.
First FAT (File Allocation Table) – a table that tells you which clusters belong to a file.
Second FAT (optional, backup).
Root Directory – a list of files (each entry is 32 bytes).
Data Area – the actual file content, split into clusters (usually 512 bytes per cluster).

Names in the root directory use the 8.3 format (e.g. HELLO BIN). Each cluster is a chain: a number in the FAT points to the next cluster; 0xFFF means end of file.

🔧 Reading a file step by step

1. Read the boot sector first

The boot sector (sector 0) contains the BPB. From there I read:

BytesPerSector (usually 512)
SectorsPerCluster (usually 1 for floppies)
ReservedSectors (often 1)
NumFATs (usually 2)
SectorsPerFAT
RootDirEntries (224 for a standard 1.44 MB floppy)

These values tell me where the FAT, root directory, and data area start.

2. Locate the file in the root directory

The root directory starts after the boot sector and both FATs:

root_dir_sector = reserved_sectors + (num_fats * sectors_per_fat);

I load the root directory into memory and scan each 32‑byte entry. I compare the name (padded with spaces) to the file I’m looking for, e.g. "HELLO BIN".

Follow the cluster chain

Once I have the first cluster number from the directory entry, I read that cluster from the data area:
c

first_data_sector = root_dir_sector + (root_dir_entries * 32 + bytes_per_sector - 1) / bytes_per_sector;
cluster_sector = first_data_sector + (cluster - 2) * sectors_per_cluster;

Then I use the FAT to find the next cluster:

Load the FAT sector that contains the entry for my cluster.
Read the 12‑bit value (FAT12 uses 12‑bit entries).
If the value is 0xFFF (or 0xFF8–0xFFF) – end of file. Otherwise, move to that cluster and repeat.

🐞 Problems I ran into

Wrong first sector of root directory – I forgot to add the reserved sectors. Always recalculate.

Cluster numbers start from 2 – I tried to use cluster 0 as the first data cluster. No.

Reading beyond the sector – I had to handle cases where a cluster spans two FAT sectors.

Disk geometry – The BIOS int 0x13 expects CHS (cylinder/head/sector). I had to convert LBA to CHS manually. It’s annoying but doable.

Debugging was a pain. I printed sector numbers to the screen (using video memory at 0xB8000) to see what was actually being read.
🎉 Result

Now my kernel can load a file from disk:
bash

load HELLO.BIN
Loading HELLO.BIN ... done.
Executing...
Hello from user program!

I can write small assembly programs, compile them into a raw binary, and copy them to a FAT12 floppy image. Then Paull‑kernel loads and runs them.

🔜 What’s next

A dir command to list all files in the root directory.
Better error handling (file not found, end of disk).
Maybe later: support for long file names (LFN) or FAT32.

🔗 Links

Source code of Paull‑kernel: github.com/Paullknya/Paull-kernel
Discuss this article: Community forum
My GitHub profile: github.com/Paullknya

Happy low‑level coding! 🦫

Why my keyboard handler caused #GP (and how I fixed it)

Paull Knya-z — Wed, 20 May 2026 08:09:03 +0000

— A true story of debugging a 32‑bit kernel

A few weeks ago I was happily writing my own 32‑bit x86 operating system, Paull-kernel. Everything worked: the bootloader, protected mode, a simple “Hello” message. Then I decided to add keyboard input.

I wrote an IRQ1 handler, compiled, ran… and QEMU crashed hard with a General Protection Fault (#GP) on every key press. Triple fault. Reboot loop. Frustration.

After two hours of staring at the code, I finally understood the problem – and it wasn’t inside the handler logic. It was two stupid mov instructions.

🧠 What I wanted to do

Catch keyboard interrupts (IRQ1) and read scancodes from port 0x60.
Convert scancodes to ASCII characters and print them to the screen.
Simple, classic OS‑dev step.

My handler looked (mostly) correct: read scancode, skip key‑release, translate via a table, write to video memory.

💥 What went wrong

Every key press caused #GP. The processor reset. No error message, no debugging output – just a black screen.

Here’s the piece of code that broke everything:

keyboard_handler:
    pushad
    mov ax, 0x1000
    mov ds, ax
    mov ax, 0xB800
    mov es, ax
    in al, 0x60
    ...

Can you spot the error?
🔍 The investigation

In real mode (16‑bit), mov ds, ax with ax = 0x1000 would set the data segment to physical address 0x10000.
In protected mode (32‑bit), segment registers hold selectors – indexes into the GDT (Global Descriptor Table).

0x1000 is a garbage selector – it points to no valid descriptor.

0xB800 is also a garbage selector.

Loading them doesn’t trigger an immediate fault, but as soon as the CPU tries to access memory through ds or es (e.g., stosw with es), it throws #GP.

The handler looked like it should work, but the environment was completely different from real mode.
✅ How I fixed it

My GDT uses the flat memory model:

Code selector: 0x08

Data selector: 0x10 (base = 0, limit = 4 GiB)

So I changed two lines:


keyboard_handler:
    pushad
    mov ax, 0x10        ; correct data selector
    mov ds, ax
    mov es, ax
    in al, 0x60
    ...

And for video memory, I stopped using segment overrides. Instead, I write directly to the linear address 0xB8000:


mov edi, [cursor_pos]
shl edi, 1
add edi, 0xB8000
mov ah, 0x07
stosw

No more es magic. Now the handler works perfectly.
📦 Key takeaways

In protected mode, segment registers store GDT selectors, not physical addresses.

Values like 0x1000 or 0xB800 are almost always invalid and will cause #GP when accessed.

Always check your GDT and use the correct selectors (e.g. 0x08 for code, 0x10 for data).

When writing to video memory, use the linear address 0xB8000 and a flat‑mapped ds/es.

One small mistake can cost you hours of debugging. But once you understand the model, it becomes obvious.
🔗 Links & resources

Source code of AxonOS (full kernel + bootloader):
👉 github.com/Paullknya/AXonOS-kernel

My GitHub profile:
👉 github.com/Paullknya

Discuss this article on the community forum:
👉 paullknya.github.io

🚀 What’s next?

Next article I’ll show how I added ring 0/3 switching and why sudo reboot asks for a password.
If you’re interested, follow me or star the repo – it helps a lot.

Happy coding, and may your selectors always be valid.

Writing a Bootloader for My OS: Common Pitfalls and How I Fixed Them

Paull Knya-z — Wed, 20 May 2026 07:41:54 +0000

Writing a Bootloader for My 32-bit x86 OS: Common Pitfalls and How I Fixed Them

I decided to write my own 32-bit x86 operating system from scratch. The first step was a bootloader – the small piece of code that loads the kernel. It’s supposed to be simple, but I ran into several frustrating issues. This post documents the real problems I faced and how I solved them, so you can avoid the same traps.

1. The BIOS signature

The boot sector must end with the magic bytes 0x55AA. The BIOS checks these two bytes before loading the sector. I forgot them, and nothing happened.

Fix: Add dw 0xAA55 at the end of your bootloader code, after filling the rest of the 512-byte sector with zeros.

times 510-($-$$) db 0
dw 0xAA55

Losing the boot drive number

The BIOS passes the disk number in the dl register. I accidentally overwrote it before using it in the int 0x13 call. The disk read failed silently.

Fix: Save dl right at the start:


mov [boot_drive], dl

Then restore or use the saved value when reading sectors.

A20 line – the hidden gatekeeper

To access memory above 1 MB and enter 32‑bit protected mode, the A20 line must be enabled. I wasted hours trying to figure out why my far jump crashed. The quickest way (though not the most universal) is to use port 0x92.


in al, 0x92
or al, 2
out 0x92, al

Many emulators enable A20 by default, but real hardware doesn’t – always include this step.

Global Descriptor Table (GDT) mistakes

A flat memory model requires at least two descriptors: code and data. I messed up the segment limits and flags, causing general protection faults.

Correct minimal GDT for flat model (32‑bit):


gdt_start:
    dq 0                       ; null descriptor
    dw 0xFFFF, 0x0000, 0x9A00, 0x00CF   ; code segment 0x08
    dw 0xFFFF, 0x0000, 0x9200, 0x00CF   ; data segment 0x10
gdt_end:

Load it with lgdt [gdt_desc] before switching to protected mode.

The protected mode jump

After setting the PE bit in cr0, you must perform a far jump to reload CS with the new code segment selector. I initially forgot the jmp and the CPU continued with the old real‑mode CS, causing a triple fault.


mov eax, cr0
or eax, 1
mov cr0, eax
jmp 0x08:protected_mode   ; 0x08 is our code segment selector

Segment registers in protected mode

Inside the kernel (or later, in interrupt handlers), I naively loaded ds = 0x1000 and es = 0xB800, assuming they would work like in real mode. That’s wrong – in protected mode they must hold selectors (indices into GDT). This caused instant #GP.

Fix: Use the data segment selector (0x10) and access video memory directly by its linear address:


mov ax, 0x10    ; data selector
mov ds, ax
mov es, ax

; Write character via linear address 0xB8000
mov edi, [cursor_pos]
shl edi, 1
add edi, 0xB8000
mov ah, 0x07
mov [edi], ax

Result: a working bootloader + kernel

After fixing these issues, the bootloader loads the kernel, enters protected mode, and runs a simple command line. Everything is open source.

GitHub repository: github.com/Paullknya/AXonOS-kernel
Project discussions and updates: paullknya.github.io

If you’re also writing a hobby OS, I hope this saves you a few hours of debugging. Feel free to ask questions in the discussions – I’ll be happy to help.

Happy coding!

my OS link: https://github.com/Paullknya/AXonOS-kernel