list of current bugs as of 19-feb-09


time:

hour for 08 reports 81
date reports for year +2000 as 217,otherwise TWO digit code.
--NOT y2k compliant. use four year codes.

output of date.year is fixed, but this is not Y2K compliant.its just a
quick hack.not sure about the 217.

heap hints(broken compile):
[first you have xxx.bitmap.pas in the kernel folder and im assuming this is
because you forgot to rename them??]

pmm.pas(31,48) Hint: Mixing signed expressions and longwords gives a 64bit
result
pmm.pas(128,19) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(147,20) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(162,12) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(169,14) Hint: Conversion between ordinals and pointers is not portable
pmm.pas(170,9) Hint: Conversion between ordinals and pointers is not portable
vmm.pas(58,19) Hint: Conversion between ordinals and pointers is not portable
vmm.pas(67,37) Hint: Conversion between ordinals and pointers is not portable
vmm.pas(155,16) Hint: Conversion between ordinals and pointers is not portable

heap.pas(37,19) Error: Wrong number of parameters specified for call to
"AllocPage"

vmm.pas(52,10) Hint: Found declaration: AllocPage(PPageTableEntry):Boolean;

heap.pas(38,8) Error: Identifier not found "Map"

heap.pas(50,27) Hint: Conversion between ordinals and pointers is not portable

heap.pas(52,15) Error: Identifier not found "GetMapping"
heap.pas(53,18) Error: Incompatible type for arg no. 1: Got "LongWord",
expected "PPageTableEntry"

vmm.pas(65,11) Hint: Found declaration: FreePage(PPageTableEntry);

heap.pas(54,10) Error: Identifier not found "UnMap"

heap.pas(65,23) Hint: Conversion between ordinals and pointers is not portable
heap.pas(65,15) Hint: Conversion between ordinals and pointers is not portable
heap.pas(113,25) Hint: Conversion between ordinals and pointers is not portable
heap.pas(113,17) Hint: Conversion between ordinals and pointers is not portable
heap.pas(121,17) Hint: Conversion between ordinals and pointers is not portable
heap.pas(124,16) Hint: Conversion between ordinals and pointers is not portable
heap.pas(128,14) Hint: Conversion between ordinals and pointers is not portable
heap.pas(137,13) Hint: Conversion between ordinals and pointers is not portable
heap.pas(144,19) Hint: Conversion between ordinals and pointers is not portable
heap.pas(144,11) Hint: Conversion between ordinals and pointers is not portable
heap.pas(150) Fatal: There were 5 errors compiling module, stopping

im using the old one for now.

keyboard:

please look at

procedure KeyboardHandler(var r: TRegisters);

in
keybrd.pas.

functionkeys and keys not in letters,numbers,enterKey do not work as
intended. the kernel panics when you press these keys.
[on simulator or real hardware.] This includes up and down arrows and
backspace.

assuming that this is because there doesn't seem to be a second 'readkey'
call. You need TWO for extended codes.
I placed another one in place,but not sure if it's going to work.

the key codes should be listed in the  const section now.

display routines:

i wouldn't replace your calls just yet, let fullansi engage itself after
the rest of the kernel loads. I had some issues in the past with getting
this working.it works fine now.

writestrln, writestring, and settextcolor should be the only overlapping
routines.

dos:

NOT TESTED, some routines are missing from the RTL. It seems, and this is
weird, that routines that should be present are being pulled out of thin
air.I know these routines exist, but they are not in go32 or dos units, or
thier includes, which I have included within our DOS unit.

some necessary  fileIO routines are missing because of this.

ALSO, the FPC programmers didn't intend on this unit ever compiling, as it
is flawed and chock full of syntax [and some logic] errors. I have fixed
these in our unit. That is why parts are incomplete.

 also we do not need 'fpc_dosomething' procedures, those are for the
compiler, which is why the unit is usually in the RTL, not your project.
They just define what is configured [in this case from dos] as far as
IsMemory manager present and similar calls. we neither need these or have
to implement them.

I think I setup mem[] construct correctly, linux targets seem to need a two
dimensional array when dos [go32] target only seems to need one.There is a
workaround for mem[] easily available and easy to configure.

I hate peeking and poking as well[writeport,readport], but some things have
to have direct hardwareIO, at least for now.

would urge someone to help fix these issues as I work on getting a
filesystem and stable dos unit.

these are annoyances for me, but BIG issues for end users. everything else
works the way it should.
Original issue reported on code.google.com by jasm...@lavabit.com on 19 Feb 2009 at 8:42
raouf505 / fpos

list of current bugs as of 19-feb-09 #8
