DEV Community: Pilder Of

⚠️ ARE YOU AWARE OF THE DANGER?

Pilder Of — Tue, 13 Oct 2026 22:44:58 +0000

Are we heading toward a problem far bigger than AI putting software developers out of work?

Over the past few years, whenever artificial intelligence has been discussed, the same question has been asked again and again:
“Will AI put software developers out of work?”
I believe we are focusing on the wrong question.
Yes, artificial intelligence will change the way software is developed. It will reduce some tasks that once took developers weeks to just hours. It will enable smaller teams to build much larger projects. It will change the nature of some professions.
But I see a much greater danger:
We are already beginning to see the first examples of this today. For the past week, people have been celebrating the same application on this and similar platforms. Applications that look extremely similar to Photoshop… Applications that reproduce the usage model of Word and Excel almost identically… Projects attempting to create counterparts to presentation, CAD, audio, video, and other professional applications with the same approach… And the defense is usually the same: “I didn’t copy the source code. I built it from scratch.”
AI may not eliminate software development itself; it may eliminate the economic value of developing original software.
These are not the same thing.
The problem is not that AI can write code.
The problem is that people are beginning to use AI not to build something new, but to reproduce in a much shorter time products that others spent years developing and turning into successful businesses.
We are already beginning to see the first examples of this.
Applications that look extremely similar to Photoshop…
Applications that reproduce the usage model of Word and Excel almost identically…
Projects attempting to create counterparts to presentation, CAD, audio, video, and other professional applications with the same philosophy…
And the defense is usually the same:
“I didn’t copy the source code. I wrote it from scratch.”
But what exactly did you create from scratch?
The code?
Or the product?
I believe that in the coming years, we will have to seriously discuss the difference between these two concepts. Yapıştırılan markdown
“Open source feeds on the existence of closed-source software. Commercial software becomes stronger because open source exists as an alternative. Would Linux have developed this quickly if Windows had never existed? Would GNOME have progressed this far without the user-experience innovations introduced by macOS? If one half of an ecosystem disappears, the other half begins to dry up as well. Competition does not merely reduce prices; it forces both sides to become better. If AI destroys one side of this competition, the remaining side will slow down too. In the end, everyone loses.”

Writing code from scratch is not the same as developing a product from scratch
When a company develops software, it does not merely write source code.
First, it discovers which problem needs to be solved.
It makes wrong decisions.
It builds prototypes that fail.
It learns how users behave.
It develops an interface.
Then changes it.
It fixes thousands of bugs.
It collects customer feedback for years.
It creates file models, workflows, architectures, and user habits.
Sometimes hundreds, sometimes thousands of engineers work on this.
Eventually, a successful product emerges.
Then another team looks at that successful product and says:
“These are the features.
This is the workflow.
When the user clicks here, this happens.
This file opens this way.
The menus are here.
The users have already learned how it works.
Now let’s rewrite the same behavior.”

The two sides have not taken the same risk.
The second team may genuinely have written the source code from scratch.
But it did not solve the problem from scratch.
It entered the exam after seeing the answer.
AI may change the economic rules of the game precisely at this point. Yapıştırılan markdown
Imagine an automobile
Imagine that a highly advanced automobile is developed in 2026.
The company spends billions of dollars on it.
It develops new safety technologies.
It works on a new engine.
It researches new battery technologies.
It employs thousands of engineers.
Hundreds of prototypes are thrown away.
Millions of kilometers of testing are completed.
Then another technology appears.
This technology can examine the finished automobile and, in a very short time, produce another automobile that provides the same functions and the same behavior.
The second manufacturer does not need to repeat most of the research performed by the first company.
Because the correct answer is already in front of it.
At first, this looks fantastic for consumers.
Cars become cheaper.
Hundreds of manufacturers suddenly appear.
But what happens next?
Who develops the 2027 model?
Why would a company invest several billion dollars in a new braking technology?
Why conduct new battery research?
Why pay the salaries of 10,000 engineers?
Because the moment its research succeeds, the result of that investment can be reproduced at a fraction of the cost.
After a while, the market may contain hundreds of automobile brands.
Yet in 2046, we might still be using different-looking variations of 2026 technology.
Because:
Increasing the number of products is not the same as increasing innovation.
The software industry may be facing exactly this risk. Yapıştırılan markdown
Will we still be using Office 2026 in 2046?
Imagine for a moment that Microsoft stops developing genuinely new Office technologies after 2026.
Adobe stops developing new graphics technologies.
Autodesk stops researching new CAD paradigms.
SAP stops investing in new approaches to enterprise systems.
Apple, Google, and other major technology companies stop taking the same level of risk in new user experiences and platform technologies.
But the market contains hundreds of alternatives.
Hundreds of Word-like applications.
Hundreds of Excel-like applications.
Hundreds of Photoshop-like applications.
Dozens of CAD systems.
Thousands of ERPs.
At first glance, it looks like enormous diversity.
But when we look closely, most of the fundamental ideas are still from 2026.
Because everyone reproduced what had already succeeded, while very few people invented something that had not existed before.
That is the future I am afraid of. Yapıştırılan markdown
“Will AI put software developers out of work?” That is not the real issue
I believe this is one of the biggest mistakes in the current AI debate.
Of course, AI performing the work of a software developer can have economic consequences.
But there may be a much larger problem:
The economic value of what software developers produce may collapse.
That is far more dangerous.
People start software companies today with an expectation:
If I develop a good and original product, customers will pay for it.

Investors put money into those companies for the same reason:
This team can create something new and earn revenue from the economic value it creates.

Now imagine that equation changes.
A startup works for five years.
It pays 20 employees.
It spends millions.
It develops something genuinely new.
The product succeeds.
Six months later, another team uses AI to reproduce most of the product’s behaviors, workflows, and functionality and distributes it for free.
What will the next investor say?
Probably:
“Why should I finance five years of research for the first company?”

If we cannot answer that question, that is where the real disaster begins.
Not because people lose their jobs.
Because new ventures never begin at all. Yapıştırılan markdown
What happens if the developer mindset changes?
Until now, one of the fundamental questions of entrepreneurship has been:
“What problem do people have that nobody has solved yet?”

What happens if, in the age of AI, that question becomes:
“Which successful and expensive product can I reproduce faster?”

Today Photoshop.
Tomorrow Office.
Then CAD.
Then ERP.
Then CRM.
Then accounting software.
Then broadcast automation.
Then hospital software.
Then engineering software.
Someone gathers consultants who understand SAP processes and develops a SAP-like system.
Someone finds people who deeply understand Turkish accounting regulations and develops a Logo-like system.
Someone else reproduces the workflow of a broadcast automation platform.
Another team targets an original startup product that 15 people spent years creating.
And all of them say the same thing:
“We didn’t steal the code.”
Maybe they really did not.
But that does not eliminate the economic problem.
Because every successful product begins to become a free R&D document for the next team. Yapıştırılan markdown
This may also damage people’s ability to imagine
I do not believe this is only an investor problem.
We may be teaching an entire generation of developers the wrong behavioral model.
Today, we can do extraordinary things with AI.
A project that once required 100 people may become possible with 10.
Perhaps an entirely new operating system model can be developed.
Perhaps the concept of ERP can be redesigned from the ground up.
Perhaps a completely new model of working with data can replace today’s spreadsheet paradigm.
Perhaps we can discover an entirely new creative-production paradigm beyond the approach Photoshop has followed for 35 years.
To me, this is the real value of AI.
Enabling people to build things they could never build before.
But if we spend all of that energy asking:
“How can I recreate this successful application?”

then AI may end up constraining human imagination to the boundaries of existing products instead of expanding it.
Eventually, a new developer sees Photoshop and no longer asks:
“How can I surpass this?”

Instead, they ask:
“How can I reproduce this?”

That is the real intellectual loss. Yapıştırılan markdown
Why do large companies matter?
Nobody has to like Microsoft, Adobe, or SAP.
I also believe high licensing fees, mandatory subscription models, and certain monopolistic behaviors deserve criticism.
But there is another reality:
Large-scale technology R&D requires enormous amounts of money.
Sometimes new technology can emerge from a few developers working from home.
History is full of such examples.
Steve Wozniak and the spirit of the Homebrew Computer Club are excellent examples.
Sharing knowledge and giving ordinary people access to computing were important parts of the personal-computer revolution.
But building a prototype is not the same as sustainably producing technology that millions of people can safely use.
You need engineers.
You need manufacturing.
You need testing.
You need distribution.
You need support.
You need R&D.
And most importantly:
You need capital to be allowed to fail.
Failure is part of research.
A company may test 100 ideas, and perhaps 90 of them never become products.
The successful 10 pay for the failed 90.
If successful products can no longer generate revenue, the freedom to fail disappears.
And eventually, research disappears too. Yapıştırılan markdown
If Microsoft stops, it is not only Windows that stops
This is one of the most overlooked aspects of the issue.
When Microsoft develops new operating-system technologies, Windows is not the only thing that advances.
When Apple creates new user experiences, macOS is not the only thing that advances.
When Google invests in Android, Android is not the only platform that benefits.
The competition they create puts pressure on the entire industry.
Microsoft develops one technology.
Apple produces a different answer.
Google develops another approach.
The Linux world creates its own solution.
Sometimes the direction is reversed.
Ideas born in Linux influence other platforms.
Open-source technologies enter commercial products.
This mutual competition is one of the engines of technological progress.
We cannot remove several major cylinders from that engine and expect the rest to continue running at the same speed. Yapıştırılan markdown
Linux is free; Linux engineering is not
That is why saying:
“It does not matter if Microsoft is damaged; Linux exists.”

is a major mistake.
Linux source code may be open and free.
But the time of the people developing Linux is not free.
Today’s Linux ecosystem is not built only by volunteers coding at night in their homes.
IBM/Red Hat, Intel, AMD, NVIDIA, Google, Microsoft, Canonical, SUSE, and many other companies have invested engineering resources into Linux and the technologies surrounding it for years.
The kernel is developed.
Compilers are developed.
GPU support is developed.
Mesa is developed.
File systems are developed.
Security infrastructure is developed.
GNOME and KDE are developed.
Wayland and the graphics infrastructure around it are developed.
Hardware support is developed.
A significant portion of this work exists within an economic model.
Open source does not mean free engineering.
The code may be free.
The engineer’s life is not. Yapıştırılan markdown
If the commercial world collapses, open source cannot remain independent of it
Another problem then appears.
What will major companies do when they realize their products can easily be behaviorally reproduced using AI?
They will probably try to protect themselves.
More functionality may move to servers.
APIs may be closed.
Some features of file formats may become more controlled.
Protocols may become proprietary.
Account, device, and cloud dependencies may increase.
Critical technology may no longer exist inside client software.
Because anything that remains on the client can be observed and behaviorally reproduced by a competitor.
Consider the irony:
Uncontrolled replication that begins with the goal of “freeing software” may push major producers toward building even more closed systems.
One of the groups that would suffer from this is, again, Linux and open source.
Because one of the great strengths of the open-source ecosystem is interoperability.
Being able to read formats.
Being able to use hardware.
Being able to communicate through protocols.
Being able to integrate with systems.
When companies begin raising their walls to protect themselves, clone applications will not be the only ones affected.
The entire open ecosystem will be affected. Yapıştırılan markdown
Open source is not the enemy in this discussion
I especially do not want to be misunderstood here.
My objection is not to open source.
Open source is one of the most important production models in modern technological history.
Linux is one of its clearest examples.
Open source and commercial software are not natural enemies.
On the contrary, they can form an extremely successful symbiosis.
A commercial company earns money.
It employs engineers.
Those engineers contribute to open-source projects.
The open-source infrastructure becomes stronger.
Other companies build products on top of it.
New markets emerge.
The economic relationship behind this model is one of the reasons Linux can today be found everywhere from data centers and supercomputers to embedded devices and Android.
The problem is not open source.
The problem is:
turning the reproduction of as much economic value as possible from a successful product—without taking the innovation risk borne by the original creator—into the dominant business model.

These are not the same thing. Yapıştırılan markdown
Small software companies may suffer before the giants do
Perhaps this is the most tragic part.
Microsoft has billions of dollars in cash reserves.
Adobe has a legal department.
SAP has an enormous enterprise network.
What does a 12-person software company have?
An idea.
A product.
And several years of work.
It develops genuinely new software.
It succeeds.
A year later, 30 developers use AI to reproduce most of its functionality.
Then release it for free.
Can that small company afford five years of litigation?
Can it survive a price war?
Can it continue paying a 50-person R&D team?
Probably not.
That means a movement that begins with the claim that:
“We are breaking the monopolies of Big Tech.”

may paradoxically eliminate small independent producers first.
And when the small company disappears, the next new idea may disappear with it. Yapıştırılan markdown
What happens when the people doing this have their own product copied?
I believe this is one of the most important tests of the issue.
Imagine a team that today defends the behavioral reimplementation of products made by Adobe, Microsoft, or another company.
Tomorrow, another team applies exactly the same method to them.
They do not take a single line of their source code.
They do not use their trademarks.
But they reproduce their features, user experience, workflows, and behaviors.
Then they release it for free.
What will they say?
“They didn’t steal our code, so there is no problem.”

Will that be their response?
If so, where will they get the money to pay their engineers?
How will they finance R&D for their next product?
Why would an investor provide them with capital?
If they object, why should the principle they apply to other companies not also apply to themselves?
I believe this question should be asked not only about a specific project or developer, but about the entire software industry in the age of AI. Yapıştırılan markdown
Lower prices and destroying value are not the same thing
I am not defending expensive software.
Competition should reduce prices.
There should be alternatives.
There should be open source.
Microsoft should have competitors.
Adobe should have competitors.
SAP should have competitors.
They should even be surpassed by products that do things they cannot.
But genuine competition says:
“You built this. I will build something better.”

It does not say:
“You spent years developing this. I saw the finished result, and I will reproduce the same thing more cheaply.”

These are not the same economic behavior.
The first accelerates innovation.
If the second becomes dominant, competition may begin consuming innovation itself. Yapıştırılan markdown
In the future, code may no longer be the scarce resource
In the age of AI, code may become increasingly cheap.
Perhaps in a few years, producing thousands of lines of software will cost very little.
Then the truly scarce resources will change.
Imagination.
New ideas.
The willingness to take risks.
Domain expertise.
Research.
Capital.
And a person’s ability to say:
“I will build something that has never existed before.”

If we devalue these things, AI may give us enormous quantities of software.
But very little new technology.
That is why I believe the most important question facing the software industry is not:
“Will AI put software developers out of work?”
The more important question is:
Could AI make developing genuinely new software economically irrational?

Because if a developer loses one job, another business model may eventually emerge.
But if society loses the reason to create something new, there may be nothing to replace it. Yapıştırılan markdown
Final thought
Imagine that we had stopped in 1998.
Imagine that from that point onward, we had only repeatedly reproduced the computers, operating systems, connection technologies, storage devices, and software of that era.
Every year we might have created prettier icons.
We might have produced hundreds of operating systems in different colors.
We might have had thousands of applications.
But how many of them would truly have moved beyond 1998?
Today, AI may be giving us one of the most powerful production tools in human history.
We can use it to reproduce the successful products of the past more quickly.
Or we can use it to create things we have never imagined before.
That choice will not merely determine the revenues of today’s software companies.
It will determine what technologies we are using in 2046.
And my real question is:
If reproducing yesterday’s successful ideas becomes cheaper, safer, and more profitable than financing tomorrow’s ideas, who will invent the future?

So I ask you once again: Are we aware of the danger?

Delphi’de interface mi abstract class mı tercih edilmeli?

Pilder Of — Tue, 06 Oct 2026 00:04:37 +0000

Servis ve repository sözleşmelerinde interface ile abstract class arasında karar verirken hangi kriterleri kullanıyorsunuz?
Servis ve repository sözleşmelerinde interface ile abstract class arasında karar verirken hangi kriterleri kullanıyorsunuz?

Bağlam
Bu soruda özellikle üretim ortamında uygulanabilir, gerekçesi açıklanmış yaklaşımlar arıyoruz. Yalnızca kısa bir teknoloji adı vermek yerine hangi koşulda neden o yaklaşımı seçtiğinizi belirtmeniz diğer kullanıcılar için daha faydalı olacaktır.

Değerlendirmek istediğimiz noktalar
Birden fazla sözleşmeyi uygulama ihtiyacı
Ortak kod paylaşımı ve state taşıma gereksinimi
Test double/mocking kolaylığı
Örnek kod, mimari şema, ölçüm sonucu veya hata ayıklama adımı paylaşabiliyorsanız cevabınızı daha somut hâle getirebilirsiniz.

[Boost]

Pilder Of — Tue, 06 Oct 2026 00:01:56 +0000

Pilder Of

Sep 22

LAL OS: Building an Independent Operating System with Delphi / Object Pascal-100% Turkish National Operating System

#osdev #ios #delphi #ai

7 min read

LAL OS: Building an Independent Operating System with Delphi / Object Pascal LAL OS is an independent x86 operating system project being developed in Türkiye. It is not a Linux distribution, not a Windows shell, and not a desktop environment running on to

Pilder Of — Tue, 22 Sep 2026 13:32:14 +0000

[Boost]

Pilder Of — Tue, 22 Sep 2026 13:26:19 +0000

Pilder Of

Sep 22

LAL OS: Building an Independent Operating System with Delphi / Object Pascal-100% Turkish National Operating System

#osdev #ios #delphi #ai

7 min read

LAL OS: Building an Independent Operating System with Delphi / Object Pascal-100% Turkish National Operating System

Pilder Of — Tue, 22 Sep 2026 13:24:58 +0000

LAL OS: Building an Independent Operating System with Delphi / Object Pascal

`
qbs offical site

LAL OS is an independent x86 operating system project being developed in Türkiye.

It is not a Linux distribution, not a Windows shell, and not a desktop environment running on top of another operating system.

The project is being built as a complete operating-system stack, from the boot process and kernel to storage, networking, TUI, graphics, GUI architecture and application/runtime layers.

One of the most unusual aspects of the project is the technology behind it:

a significant part of LAL OS is being developed with Delphi / Object Pascal.

For many developers, Delphi is associated primarily with desktop applications, enterprise software and database systems.

With LAL OS, we are exploring how far Object Pascal can be pushed into low-level systems engineering.

From Boot to Desktop

The architecture is being developed around our own system chain:

Firmware / Disk
      ↓
LAL Bootloader
      ↓
LAL Kernel
      ↓
System Services
      ↓
TUI / Shell
      ↓
Graphics / GUI / Applications

The goal is to keep the fundamental operating-system layers under our own architectural control rather than building the system around an existing Linux or Windows runtime.

LAL OS currently targets the x86 platform, while the architecture continues to evolve toward broader hardware and multicore support.

Kernel Development

The kernel side includes work around:

memory management
tasking and scheduling
interrupt and exception handling
kernel/user execution boundaries
system APIs
process infrastructure
device discovery
disk and hardware services

We are also actively working on SMP and multicore architecture.

The objective is not merely to enumerate CPU cores. The scheduler, tasking model, interrupts and system services must progressively become multicore-aware.

LALFS and Disk Management

LAL OS is not intended to remain a RAM-only demonstration system.

Storage is part of the operating-system architecture.

We are developing our own disk management infrastructure together with LALFS — LAL File System.

The TUI/Shell layer already provides system-oriented commands for filesystem and disk operations, including operations such as directory management, disk formatting and system control.

The larger objective is to expose storage functionality through LAL OS system services rather than implementing storage logic separately inside applications.

TUI and Command Infrastructure

The graphical environment is not the only interface to the system.

LAL OS also has its own TUI / Shell layer.

This environment is intended to remain usable independently from the graphical desktop and provides access to areas such as:

filesystem operations
disk management
system information
date and time
device information
reboot
shutdown
system commands

This separation is important to us because the core operating system should not depend on the desktop being available.

Networking and SMTP

Networking is another independent system layer under development.

The networking architecture includes work around:

network-device integration
TCP/IP-oriented communication
client connections
system networking services
data transport
SMTP infrastructure

Rather than treating every network capability as application-specific code, the long-term goal is to expose reusable networking services through the operating system.

Graphics Decoders and Image Infrastructure

The graphics stack is more than a framebuffer.

LAL OS includes its own graphics/image decoding layers for handling visual assets such as:

wallpapers
icons
application images
UI resources

Keeping the decoder layer separate from the GUI framework allows additional image formats to be introduced without coupling them directly to the windowing system.

VBE / BGA as a Graphics Backend

LAL OS currently uses VBE/BGA as part of its graphics hardware abstraction.

For us, VBE is not the GUI architecture itself.

It is a backend responsible for areas such as:

display mode
resolution
framebuffer
pixel format
video memory
screen configuration

Above that backend sits the actual UI architecture.

Graphics Backend
      ↓
ZuzuGUI
      ↓
Scene
      ↓
Surface
      ↓
Compositor
      ↓
Presentation

The intention is to prevent the upper GUI system from becoming permanently coupled to one graphics backend.

ZuzuGUI and Mozaik

The graphical system is being developed around ZuzuGUI and the Mozaik desktop environment.

Instead of treating the desktop as only:

window
  ↓
bitmap
  ↓
z-order
  ↓
framebuffer

we are separating responsibilities into dedicated architectural authorities:

Window Lifecycle
Scene Authority
Surface Ownership
Compositor Authority
Retained View Tree
Input / Focus Authority
Presentation

This separation is one of the most important architectural areas of the project.

Window lifetime, rendering ownership, input routing, composition and final presentation should not all be controlled by one monolithic manager.

Hardware Work

Modern hardware support is another major workstream.

Current development areas include:

PCI / PCIe
xHCI
USB
AHCI
NVMe
keyboard and mouse
storage controllers
device discovery

QEMU and VMware are currently useful for rapid development and testing, while bare-metal hardware support continues to mature.

PE / EXE Compatibility

We are also developing an incremental PE/EXE execution infrastructure.

The goal is not to claim complete Windows compatibility.

The compatibility layer grows together with the operating system's own:

process model
loader
memory services
exception handling
threading
runtime services

This is intended as a gradual compatibility path rather than a promise of full Win32/NT compatibility.

OpenJDK Integration

OpenJDK integration is another area being prepared.

At the current stage, this work focuses on runtime layout, binaries, modules and the surrounding execution requirements.

OpenJDK is not part of the LAL OS kernel.

It is being treated as an external user-space runtime that may eventually execute on top of LAL OS as the required process, memory, threading and loader services mature.

Development Ecosystem

Our longer-term goal is to make LAL OS a platform on which developers can build software using multiple languages and toolchains.

The roadmap includes:

Delphi / Object Pascal
Free Pascal
Lazarus
C
C++
Java / OpenJDK

We are also developing our own programming-language project called Motif.

Motif is not intended merely to introduce another syntax.

The long-term objective is to create a language and execution model capable of expressing LAL OS architecture, system contracts, GUI/runtime services, and future AI-assisted development models more naturally.

Why Object Pascal?

This is one of the questions we expect most often.

The answer is simple:

Because a programming language should be judged by what can actually be engineered with it.

Operating-system development exposes a language and its toolchain to some of the hardest software-engineering problems:

memory ownership
ABI boundaries
executable formats
hardware access
interrupt handling
concurrency
scheduling
drivers
graphics
runtime design

LAL OS is our attempt to explore those boundaries with Object Pascal in a real system rather than through theoretical arguments.

Where the Project Is Today

LAL OS is still under active development.

There is a long road ahead in areas such as:

hardware compatibility
SMP maturity
networking
drivers
runtime support
application compatibility
developer tooling

But the system is growing layer by layer.

Our goal is not to create another distribution.

Our goal is to build an independent operating-system technology stack whose major architectural layers we understand and control ourselves.

From bootloader to kernel.
From disk to network.
From TUI to GUI.
From graphics backend to compositor.
From runtime infrastructure to future programming-language support.

That is what LAL OS is about.

LAL OS
Independent operating-system development from Türkiye.

Suggested DEV.to tags:

osdev,
operatingsystem,
programming,
delphi

[Boost]

Pilder Of — Tue, 22 Sep 2026 13:08:01 +0000

Pilder Of

Sep 22

LAL OS: Building an Independent Operating System with Delphi / Object Pascal-100% Turkish National Operating System

#osdev #delphi #operatingsystem #programming

7 min read

LAL OS: Building an Independent Operating System with Delphi / Object Pascal-100% Turkish National Operating System

Pilder Of — Tue, 22 Sep 2026 13:01:39 +0000

LAL OS: Building an Independent Operating System with Delphi / Object Pascal

`
qbs offical site

LAL OS is an independent x86 operating system project being developed in Türkiye.

It is not a Linux distribution, not a Windows shell, and not a desktop environment running on top of another operating system.

The project is being built as a complete operating-system stack, from the boot process and kernel to storage, networking, TUI, graphics, GUI architecture and application/runtime layers.

One of the most unusual aspects of the project is the technology behind it:

a significant part of LAL OS is being developed with Delphi / Object Pascal.

For many developers, Delphi is associated primarily with desktop applications, enterprise software and database systems.

With LAL OS, we are exploring how far Object Pascal can be pushed into low-level systems engineering.

From Boot to Desktop

The architecture is being developed around our own system chain:

Firmware / Disk
      ↓
LAL Bootloader
      ↓
LAL Kernel
      ↓
System Services
      ↓
TUI / Shell
      ↓
Graphics / GUI / Applications

The goal is to keep the fundamental operating-system layers under our own architectural control rather than building the system around an existing Linux or Windows runtime.

LAL OS currently targets the x86 platform, while the architecture continues to evolve toward broader hardware and multicore support.

Kernel Development

The kernel side includes work around:

memory management
tasking and scheduling
interrupt and exception handling
kernel/user execution boundaries
system APIs
process infrastructure
device discovery
disk and hardware services

We are also actively working on SMP and multicore architecture.

The objective is not merely to enumerate CPU cores. The scheduler, tasking model, interrupts and system services must progressively become multicore-aware.

LALFS and Disk Management

LAL OS is not intended to remain a RAM-only demonstration system.

Storage is part of the operating-system architecture.

We are developing our own disk management infrastructure together with LALFS — LAL File System.

The TUI/Shell layer already provides system-oriented commands for filesystem and disk operations, including operations such as directory management, disk formatting and system control.

The larger objective is to expose storage functionality through LAL OS system services rather than implementing storage logic separately inside applications.

TUI and Command Infrastructure

The graphical environment is not the only interface to the system.

LAL OS also has its own TUI / Shell layer.

This environment is intended to remain usable independently from the graphical desktop and provides access to areas such as:

filesystem operations
disk management
system information
date and time
device information
reboot
shutdown
system commands

This separation is important to us because the core operating system should not depend on the desktop being available.

Networking and SMTP

Networking is another independent system layer under development.

The networking architecture includes work around:

network-device integration
TCP/IP-oriented communication
client connections
system networking services
data transport
SMTP infrastructure

Rather than treating every network capability as application-specific code, the long-term goal is to expose reusable networking services through the operating system.

Graphics Decoders and Image Infrastructure

The graphics stack is more than a framebuffer.

LAL OS includes its own graphics/image decoding layers for handling visual assets such as:

wallpapers
icons
application images
UI resources

Keeping the decoder layer separate from the GUI framework allows additional image formats to be introduced without coupling them directly to the windowing system.

VBE / BGA as a Graphics Backend

LAL OS currently uses VBE/BGA as part of its graphics hardware abstraction.

For us, VBE is not the GUI architecture itself.

It is a backend responsible for areas such as:

display mode
resolution
framebuffer
pixel format
video memory
screen configuration

Above that backend sits the actual UI architecture.

Graphics Backend
      ↓
ZuzuGUI
      ↓
Scene
      ↓
Surface
      ↓
Compositor
      ↓
Presentation

The intention is to prevent the upper GUI system from becoming permanently coupled to one graphics backend.

ZuzuGUI and Mozaik

The graphical system is being developed around ZuzuGUI and the Mozaik desktop environment.

Instead of treating the desktop as only:

window
  ↓
bitmap
  ↓
z-order
  ↓
framebuffer

we are separating responsibilities into dedicated architectural authorities:

Window Lifecycle
Scene Authority
Surface Ownership
Compositor Authority
Retained View Tree
Input / Focus Authority
Presentation

This separation is one of the most important architectural areas of the project.

Window lifetime, rendering ownership, input routing, composition and final presentation should not all be controlled by one monolithic manager.

Hardware Work

Modern hardware support is another major workstream.

Current development areas include:

PCI / PCIe
xHCI
USB
AHCI
NVMe
keyboard and mouse
storage controllers
device discovery

QEMU and VMware are currently useful for rapid development and testing, while bare-metal hardware support continues to mature.

PE / EXE Compatibility

We are also developing an incremental PE/EXE execution infrastructure.

The goal is not to claim complete Windows compatibility.

The compatibility layer grows together with the operating system's own:

process model
loader
memory services
exception handling
threading
runtime services

This is intended as a gradual compatibility path rather than a promise of full Win32/NT compatibility.

OpenJDK Integration

OpenJDK integration is another area being prepared.

At the current stage, this work focuses on runtime layout, binaries, modules and the surrounding execution requirements.

OpenJDK is not part of the LAL OS kernel.

It is being treated as an external user-space runtime that may eventually execute on top of LAL OS as the required process, memory, threading and loader services mature.

Development Ecosystem

Our longer-term goal is to make LAL OS a platform on which developers can build software using multiple languages and toolchains.

The roadmap includes:

Delphi / Object Pascal
Free Pascal
Lazarus
C
C++
Java / OpenJDK

We are also developing our own programming-language project called Motif.

Motif is not intended merely to introduce another syntax.

Why Object Pascal?

This is one of the questions we expect most often.

The answer is simple:

Because a programming language should be judged by what can actually be engineered with it.

Operating-system development exposes a language and its toolchain to some of the hardest software-engineering problems:

memory ownership
ABI boundaries
executable formats
hardware access
interrupt handling
concurrency
scheduling
drivers
graphics
runtime design

LAL OS is our attempt to explore those boundaries with Object Pascal in a real system rather than through theoretical arguments.

Where the Project Is Today

LAL OS is still under active development.

There is a long road ahead in areas such as:

hardware compatibility
SMP maturity
networking
drivers
runtime support
application compatibility
developer tooling

But the system is growing layer by layer.

Our goal is not to create another distribution.

Our goal is to build an independent operating-system technology stack whose major architectural layers we understand and control ourselves.

From bootloader to kernel.
From disk to network.
From TUI to GUI.
From graphics backend to compositor.
From runtime infrastructure to future programming-language support.

That is what LAL OS is about.

LAL OS
Independent operating-system development from Türkiye.

Suggested DEV.to tags:

osdev,
operatingsystem,
programming,
delphi