A stable linux-based operating system built on FreePascal(and similar code). Borland code it seems is not needed nor easily blended in.

Licensed GPLv3 and Modified BSD licensed.(DOUBLY FREE)

I am using Pascal Pro compiler now as it uses a up-to-date DPMI layer sources (HxDPMI), which fixes and adresses several bugs in DPMI handling and 32-bit PE EXEs. It also updates the Borland RTM/RTM32 engine. Unfortunately the only way to use the handler on already build EXEs is to load resident, part of the problem when rebuilding the Compiler sources, a much easier task than for FreePascal. Pascal Pro creates PURE 32-bit EXEs, stubloaded with user-specified DPMI loaders. I am in progress of switching the compiler from Dos32a/Wdosx to HDPMI loaders.

Pascal Pro builds similar to FreePascal sources on DOS but with a lot less headaches from the RTL.

Programmer headache and assumption are as follows:

ASSUME NOTHING. ABSOLUTELY EFFING NOTHING. REALLY...NOTHING. DO not ASSUME your code will work, Do not assume others know HOW TO CODE, ASSUME NOTHING. Triple check EVERYTHING.

Assembler is used in parts where required.

The goal is to limit Real-Mode, even VM86 interactions, not cut them off altogether.This would be impossible for a fully-functional OS.However, there are 32PM access points and all EFI BIOSes link the data back to the OS.

YES, I have working BP7 on modern hardware with freedos available. I have personally patched the CRT unit to run > 3.6GHZ safely and smoothly.I dont have anything faster to test this patch on, and I doubt netbooks will be punching that much speed for ahwile. I also have the elusive newfrontier unit.

I have working custom bootloader code now. I will be adding in DPMI and pre-ELF loader code (or COFF EXE code) as soon as possible. We will be loading in similar mode to how windows loaded in the past. (stage2 loader loads kernel file directly DOS)

This is needed. GRUB sources are not well documented,the loader is a pain to remove, and does not provide the multiboot specs it says it does.I am probing these by hand instead.FURTHERMORE, booting from GRUB presets the GDT, and we CANNOT RELIABLY reset a GDT while under RING3, where PASCALMAIN code excutes after the system unit loads.

If you look at BP7 and PascalPRO system unit sources, you will see that PASCAL is actually under a Ring3 LDT, not an empty GDT area. Interrupts are actually re-assigned once the system unit(or any sources using it, practically EVERYTHING COMPILED) loads up. This presents several problems.

1) We need to reset or manually assign the GDT 2) We need to be executing in RING0, not Ring3. (so LDT is a NO-NO.) 3) Ring3 access means we need working switching code and TSS/LDTs and SYSCALLS(which are not fully tested yet.)

So basically PascalPRO needs to be compiled once(to work in FREEDOS) and AGAIN for our OS use.The internal DPMI needs to point to the kernel code, not the DPMI host we are using.

Which means: DPMI or equivalent syscall/interrupt MUST be setup. I am TESTING this NOW.

I have noticed a glitch in 32-bit DPMI modes with the READKEY function in PASCAL/FPC.This is under freedos. I have also noticed a DPMI/fdxxms.sys glitch which hangs freedos on keyboard interrupts. This is most annoying as it locks the machine in a 32-bit state and hangs it randomly.The alternative is to use himemx.sys, commonly available.

Attempts have succeeded in replacing the out-of-date readkey function.Readportb($64) and Readportb($60) have done the job of a byte comparison apparently in the FPC internal code which has gone unchecked. I tested this with some DEMO VESA apps I had lying around.I have not replaced the code, however, this is the workaround for the CRT unit.

See THIS OSes keyboard unit for details.

Dont always expect the Subversion builds to build ok. This is expected. If you want a demo, check out the source or ISO files offered.I have made available also a USB FREEDOS method for those not wanting to waste a CD(or for those without a drive).

Our bootoader will boot from either USB Pendrive or Floppy. I have a USB Floppy under BIOS emulations.

Patch files have been removed.We are treading on dangerous unexplored ice now and compatibility with FPOS is no longer guaranteed.I will back port all effective changes if necessary(community support).

Ring3 mode jump has been fixed. I was not looking at the segments correctly. AGAIN, jump MUST be in ASSEMBLER.

The MMU internal for QEMU borks if you dont have all of the CPU RAM for paging unit available. The fix is to utilize Paging at page 32 or there-abouts.Apparently the MMU doesnt function while under emulation. This works ok on REAL Hardware.This is a QEMU bug the devs have failed to fix. :(

Paging has to be implemented in assembler, at least for the switch to activate it. It appears that the code out there(even MY code) is incorrect. Page Tables are DWORDS at the BIT level manipulated, not at the BYTE level. This can be done in C, its tricky in PASCAL. I've done it in ASM. Now onto the memory manager...

Page tables have been moved. PT 768 is a waste of nearly 1GB for kernel's own use, whether we use it or not.This may be FINE in LONG MODE, but I am not writing a LONG MODE OS at this time.

Memory should not be wasted in kernel land.Moved to PT 1020 or PT4 depending on where we put the PDirectory. The lower the better.Current ASM code points here, take notice of the multiplier, this is where we point.

I have also updated GDT to FIX a 12 year old outstanding OS GLITCH allowing malicious code, and I have done this without use of NX bit.Be honest with you, M$ made it up to make up for years of BAD CODE. Linus never bothered to fix his kernel either apparently.The fix is simple enough. KEEP kernel DATA AWAY from kernel CODE. We can do this in USERLAND also, I havent gotten that far yet.

I recently forgot to do the MATH correctly and borked the GDT by accident.Apologies.

You can start learning to code from here, assuming some code will not port to FPC: http://www.learn-programming.za.net/programming_pascal_learn01.html

If you can learn TP/BP7 and calculate LINEAR addresses correctly, Pascal Pro will work with you.

C is DIFFERENT, not BETTER. C is SLOPPY RUSHED, INSECURE by DEFAULT CODE. Why is it so hard to typecheck and range check C?

PASCAL, ADA, FORTRAN, and FORTH do this by default. So what if PASCAL is a typed language and this makes development HARDER...we can do this the RIGHT way now. We can spend LESS time debugging our code and patch SECURITY holes FASTER.

The proof is in the bytecode result.

Some of the C DEVS on the net LIE to hold you back, or provide you with INCORRECT information.

TRIPLE CHECK everything against a specification MANUAL. OH, VBE3 PM Entry point should be working now.Please note its limitations. You can still do 64K bank switching in Protected Mode.

--Jazz