Re: [fpc-devel] WinCE port docs at wiki
Yury Sidorov wrote: 2. Since H2PAS dont eat MS headers the easiest way to port is to use win32 Windows unit and remove all functions which are missing in WinCE. The following list of WinCE functions can be used as reference: http://www.rainer-keuchel.de/wince/dllexports/ipaq-coredll.txt First of all there are almost no functions with A suffix and they must be removed. Also some functions exists as wrappers (SetEvent,ResetEvent). Some of them already implemented in system.pp You can start this task. Currently nobody do it. If you will start it, please write about that at wiki and specify your contacts. IMO an important question is if wince and win32 should share the windows unit or not. Does MS have common headers? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] WinCE port docs at wiki
From: Florian Klaempfl [EMAIL PROTECTED] Yury Sidorov wrote: 2. Since H2PAS dont eat MS headers the easiest way to port is to use win32 Windows unit and remove all functions which are missing in WinCE. The following list of WinCE functions can be used as reference: http://www.rainer-keuchel.de/wince/dllexports/ipaq-coredll.txt First of all there are almost no functions with A suffix and they must be removed. Also some functions exists as wrappers (SetEvent,ResetEvent). Some of them already implemented in system.pp You can start this task. Currently nobody do it. If you will start it, please write about that at wiki and specify your contacts. IMO an important question is if wince and win32 should share the windows unit or not. Does MS have common headers? The Windows unit must not be shared between win32 and wince. 1. There are separate MS headers for WinCE. 2. win32 Windows unit is generated from GNU Windows headers and it will break any modifications were made in Windows unit to support wince. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] WinCE port windows.h
1°)actual (wince 4.2) windows.h need at :
windef.h, types.h, winbase.h, wingdi.h, winuser.h, winreg.h, shellapi.h,
ole2.h, imm.h, tchar.h, excpt.h, strsafe.h
actual window.pp (from fpc 2.1.X) look at :
base.inc, errors.inc, defines.inc, struct.inc, messages.inc, ascfun.inc,
unifun.inc, unidef.inc, ascdef.inc, func.inc, redef.inc
considering that :
- many blocks are common, just organized differently (many wince
declarations i just seek in existing win32 code was already there but
in the wrong dir !)
- windows.pp organisation is clearer
- it will be easier to maintain having in the same file, same kind of
code (even for different targets but wince is also 32bits, it's very
close to win32)
- there will also the win64 port question
i propose :
a- move existing win32 files windows.pp + base.inc+errors.inc,
defines.inc, struct.inc, messages.inc, ascfun.inc, unifun.inc,
unidef.inc, ascdef.inc, func.inc, redef.inc
to rtl\win dir
b-add the following defines in every .inc file
in the interface defined block and also in the implementation block
put here all common blocks
{$ifdef WIN32}
at first, put here all existing code, then copy/paste to the common
block according to wince headers
{$endif} //WIN32
{$ifdef WINCE}
put here all wince only code
{$endif} //WINCE
Any comment ?
2°) a type ULONG_PTR is defined in rtl\win\sysosh.inc
with right define depending on 64 or 32 bits
i saw this type only for wince plateform
could it be replaced by PULONG
and ULONG definition added there ?
there are heavily used by windows
but defined with cardinal type.
regards
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Constant arrays sometimes produce incorrect data tables
Hi all I picked up this weird code generation problem (it was also present in 2.0.0). I reported it as bug 4277 today. Unfortunately I can only reproduce it in a specific context, so please e-mail me for the unit. The problem is when you define an array of constant strings. For example: const RFCMonthNames : Array[1..12] of String = ( 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'); is usually assembled as something like: TC_P$TESTARRAY_RFCMONTHNAMES DD _$PROGRAM$_L4, _$PROGRAM$_L5, _$PROGRAM$_L6, _$PROGRAM$_L7, .. DD -1,3 _$PROGRAM$_L4: DB Jan,0 DD -1,3 _$PROGRAM$_L5: DB Feb,0 DD -1,3 which is correct, but the exact same code (in a different unit) is compiled differently, causing access violations when accessed: TC_CDATETIME_RFCMONTHNAMES DD _$CDATETIME$_L2046 DD -1,3 _$CDATETIME$_L2046: DB Jan,0 DD _$CDATETIME$_L2047 DD -1,3 _$CDATETIME$_L2047: DB Feb,0 DD _$CDATETIME$_L2048 DD -1,3 _$CDATETIME$_L2048: DB Mar,0 DD _$CDATETIME$_L2049 DD -1,3 _$CDATETIME$_L2049: DB Apr,0 Regards David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] WinCE port windows.h
Oro06 wrote:
1°)actual (wince 4.2) windows.h need at :
windef.h, types.h, winbase.h, wingdi.h, winuser.h, winreg.h, shellapi.h,
ole2.h, imm.h, tchar.h, excpt.h, strsafe.h
actual window.pp (from fpc 2.1.X) look at :
base.inc, errors.inc, defines.inc, struct.inc, messages.inc, ascfun.inc,
unifun.inc, unidef.inc, ascdef.inc, func.inc, redef.inc
considering that :
- many blocks are common, just organized differently (many wince
declarations i just seek in existing win32 code was already there but
in the wrong dir !)
- windows.pp organisation is clearer
- it will be easier to maintain having in the same file, same kind of
code (even for different targets but wince is also 32bits, it's very
close to win32)
- there will also the win64 port question
i propose :
a- move existing win32 files windows.pp + base.inc+errors.inc,
defines.inc, struct.inc, messages.inc, ascfun.inc, unifun.inc,
unidef.inc, ascdef.inc, func.inc, redef.inc
to rtl\win dir
b-add the following defines in every .inc file
in the interface defined block and also in the implementation block
put here all common blocks
{$ifdef WIN32}
at first, put here all existing code, then copy/paste to the common
block according to wince headers
{$endif} //WIN32
{$ifdef WINCE}
put here all wince only code
{$endif} //WINCE
Any comment ?
As Yury said, MS doesn't share the headers either so I think it's better
to keep them completely independend.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Constant arrays sometimes produce incorrect data tables
David Butler wrote: Hi all I picked up this weird code generation problem (it was also present in 2.0.0). I reported it as bug 4277 today. Unfortunately I can only reproduce it in a specific context, so please e-mail me for the unit. The problem is when you define an array of constant strings. For example: const RFCMonthNames : Array[1..12] of String = ( 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'); is usually assembled as something like: TC_P$TESTARRAY_RFCMONTHNAMES DD _$PROGRAM$_L4, _$PROGRAM$_L5, _$PROGRAM$_L6, _$PROGRAM$_L7, .. DD -1,3 _$PROGRAM$_L4: DB Jan,0 DD -1,3 _$PROGRAM$_L5: DB Feb,0 DD -1,3 which is correct, but the exact same code (in a different unit) is compiled differently, causing access violations when accessed: TC_CDATETIME_RFCMONTHNAMES DD _$CDATETIME$_L2046 DD -1,3 _$CDATETIME$_L2046: DB Jan,0 DD _$CDATETIME$_L2047 DD -1,3 _$CDATETIME$_L2047: DB Feb,0 DD _$CDATETIME$_L2048 DD -1,3 _$CDATETIME$_L2048: DB Mar,0 DD _$CDATETIME$_L2049 DD -1,3 _$CDATETIME$_L2049: DB Apr,0 Regards David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel There are two kinds of strings, shortstrings (max. 256 bytes) and ansistrings (any length, allocated on the heap). May be they're mixed, because the declaration string might use a shortstring in one unit, an ansistring in another, depending on compiler switches like $H or $LONGSTRINGS. Such mixing would very likely cause access violations. Try e. g. to change all declarations to shortstring, which is enough for short month names. hth, Anton. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] StrToNetAddr6
Hi!
It seems that the StrToNetAddr6 function is not implemented yet
(http://svn.freepascal.org/svn/fpc/trunk/rtl/inc/sockets.inc). I wrote
an implementation (attached as file including some testcases). I hope
you can use it for the Sockets unit.
Bye
Hansi
Program IP6;
Function StrToNetAddr6(IP : String) : TIn6_addr;
Var Part : String;
IPv6 : TIn6_addr;
P,J: Integer;
W : Word;
Index : Integer;
ZeroAt : Integer;
Begin
FillChar(IPv6,SizeOf(IPv6),0);
{ Every 16-bit block is converted at its own and stored into Result. When }
{ the '::' zero-spacer is found, its location is stored. Afterwards the }
{ address is shifted and zero-filled. }
Index := 0; ZeroAt := -1;
J := 0;
P := Pos(':',IP);
While (P 0) and (Length(IP) 0) and (Index 8) do
Begin
Part := '$'+Copy(IP,1,P-1);
Delete(IP,1,P);
if Length(Part) 1 then { is there a digit after the '$'? }
Val(Part,W,J)
else W := 0;
IPv6.u6_addr16[Index] := HtoNS(W);
if J 0 then
Begin
FillChar(IPv6,SizeOf(IPv6),0);
Exit;
End;
if IP[1] = ':' then
Begin
ZeroAt := Index;
Delete(IP,1,1);
End;
Inc(Index);
P := Pos(':',IP); if P = 0 then P := Length(IP)+1;
End;
{ address a:b:c::f:g:h }
{ Result now a : b : c : f : g : h : 0 : 0, ZeroAt = 2, Index = 6 }
{ Result after a : b : c : 0 : 0 : f : g : h }
if ZeroAt = 0 then
Begin
Move(IPv6.u6_addr16[ZeroAt+1],IPv6.u6_addr16[(8-Index)+ZeroAt+1],2*(Index-ZeroAt-1));
FillChar(IPv6.u6_addr16[ZeroAt+1],2*(8-Index),0);
End;
Result := IPv6;
End;
Begin
StrToNetAddr6('1:2:3:4:5:6:7:8');
StrToNetAddr6('1:2:3::7:8');
StrToNetAddr6('1:2:3:4:5:6::');
StrToNetAddr6('::4:5:6:7:8');
StrToNetAddr6('::7:8');
StrToNetAddr6('1:2::');
StrToNetAddr6('::8');
StrToNetAddr6('::');
End;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] According to Valgrind, something is wrong in IndexByte
On Aug 13, 2005, at 10:41, Micha Nelissen wrote: On Sat, 13 Aug 2005 00:03:01 -0400 Jan Ruzicka [EMAIL PROTECTED] wrote: On Aug 12, 2005, at 05:04, Micha Nelissen wrote: But if I use my own version (which I use for delphi and is i386 specific), it reports no errors in this location, for Dbf_Common/Dbf_Memo. i386 IndexByte seems way more complex than my custom MemScan, but maybe that's necessary somehow. Have you investigated more into the Valgrind behavior? The jump (JNE @@1) is reacting to REPNE SCASB and all values seem to be defined. Valgrind may be expecting some numerical operation to set the flags. Flags Affected: None; however, the CMPS and SCAS instructions do set the status flags in the EFLAGS register. Hmm is your point that valgrind should detect an error in my REPNE SCASB ? No. Sorry did not read the original post carefully enough. My understanding was that the assembler portion was causing valgrind to complain. Now I finally got it. You were pointing out possible problem in System.IndexByte(Buffer, Length, Chr); The valgrind message is really strange, because the IndexByte function is really similar to one you advised. The svn version has this in rtl/i386/i386.inc 297 function IndexByte(Const buf;len:SizeInt;b:byte):SizeInt; assembler; 298 var 299 saveedi,saveebx : longint; 300 asm 301 movl%edi,saveedi 302 movl%ebx,saveebx 303 movlbuf,%edi // Load String 304 movbb,%bl 305 movllen,%ecx // Load len 306 xorl%eax,%eax 307 testl %ecx,%ecx 308 jz .Lcharposnotfound 309 cld 310 movl%ecx,%edx // Copy for easy manipulation 311 movb%bl,%al 312 repne 313 scasb 314 jne .Lcharposnotfound 315 incl%ecx 316 subl%ecx,%edx 317 movl%edx,%eax 318 jmp .Lready 319 .Lcharposnotfound: 320 movl$-1,%eax 321 .Lready: 322 movlsaveedi,%edi 323 movlsaveebx,%ebx 324 end; I am not familiar with the internals of valgrind, so to conclude from 1 hour valgrind-experience that valgrind is faulty would be a little over the top IMHO.. Once again sorry for the misunderstanding. Jan ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
