Initially Ace OS was started as Boot Sector program. You can get more details about the birth of Ace OS in the About page. I wrote a boot sector program, I troubled lot to make it load another program from the disk so I discard my code and searched the internet for boot code and I got a code (If I am right it was named - QUASI boot code). I have used that code quite long time and then wrote another assembly program called OSLoader.bin to load kernel in Portable Executable file format. It also setups the 32 bit protected mode before starting the Kernel. But it has the following limitation - the kernel must be less than 240KB. And it is unable to load the Kernel above 1MB memory location. Due to these limitations I have discarded the boot sector and OSLoader.bin and switch to GRUB last year. If you want to view the source code of OSLoader.bin and Boot.asm click here. These two programs are also packaged with the source downloads of previous version of Ace.

If you are new to OS development then don't try to create a boot sector program and waste your time unless otherwise your machine is not supported by GRUB.

GRUB has the following features

• Loading the following file formats
• Loading other modules
• Passing arguments to Kernel such as memory information
• VESA mode initialization
• Multiple boot options

GRUB does not have native support for PE file format. Since Ace OS Kernel is purely PE file a small trick is required to boot Ace OS using GRUB. Kernel.asm has the multi boot header structure required by the GRUB.

The following is the multi-boot structure content
dd MULTIBOOT_HEADER_MAGIC
dd MULTIBOOT_HEADER_FLAGS
dd CHECKSUM
dd mboot - VIRTUAL_BASE_ADDRESS + PHYSICAL_ADDRESS ; these are PHYSICAL addresses
dd PHYSICAL_ADDRESS ; start of kernel .text (code) section
dd _sbss - VIRTUAL_BASE_ADDRESS + PHYSICAL_ADDRESS ; end of kernel .data section
dd _ebss - VIRTUAL_BASE_ADDRESS + PHYSICAL_ADDRESS ; end of kernel BSS
dd _KernelEntry - VIRTUAL_BASE_ADDRESS + PHYSICAL_ADDRESS ; kernel entry point (initial EIP)

GRUB loads the kernel at 1MB in the physical memory and relocates the image for 3GB and transfers the control to _KernelEntry in the Kernel.asm file. Since GRUB setups the 32 bit protected mode environment Ace OS kernel starts in the protected mode and initializes other modules. It uses the argument given by GRUB to extract some information from the BIOS.

You can download grub from the following website - http://gnu.org/grub

It is a very small program used to catch all the exceptions and faults. In the current version all the Exception handlers are just prints the Exception details and halts the system. The General Protection Fault is slightly differing from other exception handlers because of the V86 mode. If the current task is in V86 mode then the GPF switches the control to V86 mode handler.

It is also used to detect the CPU type and the other information about the CPU using the CPUID instruction. During the initialization it detects the CPU and caches the result.

Memory Management is one of the hardest jobs which should be accomplished before doing anything else. The memory management modules should be initialized just after the kernel gets the control from the GRUB. The memory initialization is done in two phases. The first phase is done before switching on the Paging and the second phase initialization is done after the Paging is switched on.

Memory Management includes the following tasks, creating and maintaining GDT, LDT, IDT entries, keeping track of used and free linear space for each process separately and keeping the free physical memory bitmap.

The following files are used to implement the above tasks

1. Descriptor.C - It is used to create, modify and delete GDT and IDT entries. Ace OS still not used the LDT entries.
2. CPhysical.C - It is used to manage Physical memory and set the memory below 1MB.
3. VASM.c - It used to manage Virtual memory. This program has the functions to allocate virtual memory in a task's address space. It also has the functions to map the Virtual Address to a physical address.

RTC is the very smallest and simplest program in Ace OS. The real time clock module has the functions to get and set date values from the Motorola MC146818.

1. void GetLocalTime(SYSTEMTIME * lpSystemTime)
2. BYTE SetLocalTime(SYSTEMTIME * lpSystemTime)

Timer it has an interrupt handler to handle the interrupts generated by the 8253 timer chip. The timer chip initialized to run at 18Hz during the kernel initialization phase. The interrupt handler increments a double word variable and calls the scheduler on appropriate intervals.

Timer also has functions to create a timer which will trigger at the given millisecond. The TimerHand() function manages to trigger the timers at given interval. Here the triggering means posting a message to the messenger.

Currently graphics mode is not a part of Ace OS Kernel. However graphics can achievable in the current version using V86 mode and the VESA functions. Ace OS uses the text mode provided by VGA. It uses the memory mapped I/O to print text on the monitor.

During the memory initialization phase II, the VGA card's memory region is mapped above 3GB of kernel's address space. Using this address the VGAText.c does all operations to print the characters. VGAText.c also has two functions to set and get the size of the text mode cursor.

Ace OS uses the Priority based scheduler. The scheduling algorithm is very simple. The scheduler first selects a task with highest weight and it selects a thread from the task's thread queue.

Weight Calculation :: Weight=(TASK_PRIORITY_LEVELS-lpThread->dwPriority)*TASK_PRIORITY_RATIO + lpThread->dwWaitingTime;

The thread selection is again done using priority based algorithm. Then the scheduler initiates a task switch. Since the task switch is an expensive process it is occurs only when a new thread is selected.

Ace OS does not uses the hardware task switching mechanism provided by Intel Architecture, it uses the software stack based task switching.

The scheduler is also responsible for changing the IOBase address field in the TSS structure. This IOBase is a bitmap used to control the I/O access in the protected mode. Ace OS allows each thread to have its own IOBase address.

Don't care too much about the name. This module is an interface between storage devices and other modules. This module abstracts the storage device module. All other kernel modules and applications should use this module rather than directly calling storage device modules (Eg - Hard disk, Floppy, CDROM etc).

Each storage device handler should fill the following structure and call the GSH_Register() to register itself with GSH. GSH uses the structure to call appropriate functions when needed. If any functions is unsupported then it should set as NULL so that GSH will abort the call with ERROR_NOT_SUPPORTED error code.

struct GenericStorageHandle
{
BYTE (*GetNoOfDevices)();
UINT32 (*GetDeviceParameters)(BYTE bDeviceNo, BYTE * lpBuffer);

UINT32 (*Reset) (BYTE bDeviceNo);
UINT32 (*Status)(BYTE bDeviceNo);

UINT32 (*Verify)(BYTE bDeviceNo, LPGSHIOPARA lpIOPara);
UINT32 (*Read) (BYTE bDeviceNo, LPGSHIOPARA lpIOPara, BYTE * lpBuffer);
UINT32 (*Write) (BYTE bDeviceNo, LPGSHIOPARA lpIOPara, BYTE * lpBuffer);

UINT32 DeviceSpecific[10];
};
typedef struct GenericStorageHandle GSH;
typedef GSH * LPGSH;

The following functions are useful to handle a storage device through GSH. The DeviceKey passed to these functions is unique string given by the storage handler during initialization.
BOOLEAN GSH_Register(LPCSTR szDeviceKey, LPGSH lpGSH);
BYTE GSH_GetRegisteredDeviceTypes(BYTE (*fnFeedBack)(LPCSTR szDeviceKey));
BYTE GSH_GetNoOfDevices(LPCSTR szDeviceKey);

UINT32 GSH_GetDeviceParameters(LPCSTR szDevicePath, BYTE * lpBuffer);
UINT32 GSH_Reset(LPCSTR szDevicePath);
UINT32 GSH_Status(LPCSTR szDevicePath);

UINT32 GSH_Read(LPCSTR szDevicePath, LPGSHIOPARA lpIOPara, BYTE * lpBuffer);
UINT32 GSH_Write(LPCSTR szDevicePath, LPGSHIOPARA lpIOPara, BYTE * lpBuffer);
UINT32 GSH_Verify(LPCSTR szDevicePath, LPGSHIOPARA lpIOPara);

It is an interface to abstract File Systems and give uniform access methods to Applications and other kernel modules.

Each File System handlers should register with GFS by calling the BOOLEAN GFS_Register(LPCSTR szFileSystemName, LPFSHANDLE hFileSystem) and BOOLEAN GFS_RegisterForDevicePath(LPCSTR szDevicePath, LPFSHANDLE lpFileSystem); calls. File System handlers should fill the following structure and pass it while calling GFS_Register.

typedef struct FileSystemHandle FSHANDLE;
typedef FSHANDLE * LPFSHANDLE;
struct FileSystemHandle
{
UINT32 (*GetVolumeCapacity)(LPFSHANDLE lpFS);
UINT32 (*GetVolumeFree) (LPFSHANDLE lpFS);
UINT32 (*GetVolumeBad) (LPFSHANDLE lpFS);

UINT32 (*CreateDirectory) (LPFSHANDLE lpFS, LPCSTR lpPathName);
UINT32 (*RemoveDirectory) (LPFSHANDLE lpFS, LPCSTR lpPathName);

UINT32 (*GetCurrentDirectory) (LPFSHANDLE lpFS, DWORD nBufferLength, LPTSTR lpBuffer);
UINT32 (*SetCurrentDirectory) (LPFSHANDLE lpFS, LPTSTR lpDirPath);

HANDLE (*CreateFile)(LPFSHANDLE lpFS, LPCTSTR lpFilePath, DWORD dwOpenMode, DWORD dwShareMode, DWORD dwCreationDisposition, DWORD dwFlags );
UINT32 (*CloseFile)(LPFSHANDLE lpFS, HANDLE hFile);
UINT32 (*SetFilePointer)(LPFSHANDLE lpFS, HANDLE hFile, DWORD dwNewPos, DWORD dwMoveMethod);
UINT32 (*GetFilePointer)(LPFSHANDLE lpFS, HANDLE hFile);
UINT32 (*ReadFile)(LPFSHANDLE lpFS, HANDLE hFile, UINT32 dwNoOfBytes, void * lpBuffer);
UINT32 (*WriteFile)(LPFSHANDLE lpFS, HANDLE hFile, UINT32 dwNoOfBytes, void * lpBuffer);

UINT32 (*DeleteFile)(LPFSHANDLE lpFS, LPCTSTR lpFileName);
UINT32 (*GetFileAttributes)(LPFSHANDLE lpFS, LPCTSTR lpFileName, LPFILEINFO lpFINFO);

HANDLE (*FindFirstFile)(LPFSHANDLE lpFS, LPCTSTR lpFileName, LPFILEINFO lpFINFO);
UINT32 (*FindNextFile)(LPFSHANDLE lpFS, HANDLE hFile, LPFILEINFO lpFINFO );
UINT32 (*FindClose)(LPFSHANDLE lpFS, HANDLE hFile);


UINT32 FSSpecificFields[10];
};