WIndows Mobile - the same problems

[Jaroslaw Kadziola]

Hi all,

I fight for a long time with the problem described here:
http://groups.google.com/group/harbour-devel/browse_thread/thread/2b124684b0709a34#
Unfortunately, i do not give advice, because i have no idea about programming in c.
So i ask you (Przemek, Viktor and other professionalists) for help in solving this problem,
which will allow the activation of Harbour on systems newer than Windows Mobile 5.
My attempts to improve the operation on databases basing of these systems
(CREATE, INDEX ON, COPY TO, SET INDEX TO etc.) came to nothing.
However, I did a little test that shows how works dbCreate() under the
various WM-systems. Here's the code:

Proc Main()
Set Date Ansi
a=hb_milliSeconds()

For y =1 To 999
aDane := {}
For y =1 To 999
@1,10 Say y
AAdd(aDane, {'FIELD_' + AllTrim(Str(y,3,0)) , "C", 2, 0})
dbCreate('dane.dbf',aDane)
b=hb_milliSeconds()
? b - a
Next
Return

and results :

--------------------------------------
OS |number of fields created until
|error DOS 87 ( = y)
--------------------------------------
WM 2003| no problem
--------------------------------------
WM 5 | no problem
--------------------------------------
WM 6 | 241
--------------------------------------
WM 6.5 | 598
--------------------------------------

I did the test several times and always the same results.
Can you recommend some other tests, to finally help solve
this problem?

My compiler is mingwarm.

--
Regards,

Jaroslaw Kadziola

[Jarosław Kądzioła]

Hi all,

Really can not somebody help me ?

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Fri, 17 Dec 2010, Jaroslaw Kadziola wrote:

Hi Jarek,

> I fight for a long time with the problem described here:
> http://groups.google.com/group/harbour-devel/browse_thread/thread/2b124684b0709a34#
> Unfortunately, i do not give advice, because i have no idea about programming in c.
> So i ask you (Przemek, Viktor and other professionalists) for help in solving this problem,
> which will allow the activation of Harbour on systems newer than Windows Mobile 5.
> My attempts to improve the operation on databases basing of these systems
> (CREATE, INDEX ON, COPY TO, SET INDEX TO etc.) came to nothing.
> However, I did a little test that shows how works dbCreate() under the
> various WM-systems. Here's the code:

[...]

> OS |number of fields created until
> |error DOS 87 ( = y)
> --------------------------------------
> WM 2003| no problem
> --------------------------------------
> WM 5 | no problem
> --------------------------------------
> WM 6 | 241
> --------------------------------------
> WM 6.5 | 598
> --------------------------------------
> I did the test several times and always the same results.
> Can you recommend some other tests, to finally help solve
> this problem?
> My compiler is mingwarm.

As I wrote in one of previous messages it does not look like Harbour
problem. Probably I can suggest you only some workarounds and maybe
one of them help you to resolve the problem.
Your above test is more precise and it shows that the problem is related
to file write or seek operation.
So 1-st thing you can try is changing in src/rtl/filesys.c all (6) lines
with:
if( hb_iswinnt() )
to:
if( hb_iswinnt() || hb_iswince() )

Then rebuild Harbour for WinCE and repeat your test.
If it doesn't help then you can try to link your application with
coredll6 instead of coredll. Try to change in utils/hbmk/hbmk2.prg
line[1418]:
l_aLIBSYSCORE := { "coredll", "ws2" }
to:
l_aLIBSYSCORE := { "coredll6", "ws2" }

then rebuild HBMK2 for your native platform and use it to link your
WinCE test application.

If it doesn't help too then we can try to locate more precisely which
operation fails.

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

> Hi Jarek,

Many thanks for your help. Tomorrow morning I will start with tests

Regards,
Jaroslaw Kadziola

[Jaroslaw Kadziola]

Hi Przemek,

PC> On Fri, 17 Dec 2010, Jaroslaw Kadziola wrote:

PC> Hi Jarek,

>> I fight for a long time with the problem described here:
>> http://groups.google.com/group/harbour-devel/browse_thread/thread/2b124684b0709a34#
>> Unfortunately, i do not give advice, because i have no idea about programming in c.
>> So i ask you (Przemek, Viktor and other professionalists) for help in solving this problem,
>> which will allow the activation of Harbour on systems newer than Windows Mobile 5.
>> My attempts to improve the operation on databases basing of these systems
>> (CREATE, INDEX ON, COPY TO, SET INDEX TO etc.) came to nothing.
>> However, I did a little test that shows how works dbCreate() under the
>> various WM-systems. Here's the code:

PC> [...]

>> OS |number of fields created until
>> |error DOS 87 ( = y)
>> --------------------------------------
>> WM 2003| no problem
>> --------------------------------------
>> WM 5 | no problem
>> --------------------------------------
>> WM 6 | 241
>> --------------------------------------
>> WM 6.5 | 598
>> --------------------------------------
>> I did the test several times and always the same results.
>> Can you recommend some other tests, to finally help solve
>> this problem?
>> My compiler is mingwarm.

PC> As I wrote in one of previous messages it does not look like Harbour
PC> problem. Probably I can suggest you only some workarounds and maybe
PC> one of them help you to resolve the problem.
PC> Your above test is more precise and it shows that the problem is related
PC> to file write or seek operation.
PC> So 1-st thing you can try is changing in src/rtl/filesys.c all (6) lines
PC> with:
PC> if( hb_iswinnt() )
PC> to:
PC> if( hb_iswinnt() || hb_iswince() )

PC> Then rebuild Harbour for WinCE and repeat your test.

Done, but the same error occur in the same place.

PC> If it doesn't help then you can try to link your application with
PC> coredll6 instead of coredll. Try to change in utils/hbmk/hbmk2.prg
PC> line[1418]:
PC> l_aLIBSYSCORE := { "coredll", "ws2" }
PC> to:
PC> l_aLIBSYSCORE := { "coredll6", "ws2" }

PC> then rebuild HBMK2 for your native platform and use it to link your
PC> WinCE test application.

Done, but the same error occur in the same place.

What else can I try?

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Wed, 22 Dec 2010, Jaroslaw Kadziola wrote:

Hi Jarek,

> PC> So 1-st thing you can try is changing in src/rtl/filesys.c all (6) lines
> PC> with:
> PC> if( hb_iswinnt() )
> PC> to:
> PC> if( hb_iswinnt() || hb_iswince() )
> PC> Then rebuild Harbour for WinCE and repeat your test.
> Done, but the same error occur in the same place.

Anyhow good to know that we can use MT safe atomic read/write and
seek operations for this WinCE. We should update filesys.c code.

[...]

> Done, but the same error occur in the same place.
> What else can I try?

So let's check what is the exact error.
Add to modified filesys.c at line 1916, just after:
nWritten = dwWritten;
this code:
{
char buf[1024];
hb_snprintf( buf, sizeof( buf ),
"\r\n[dwWritten=%lu, nCount=%lu, error=%lu]\r\n",
dwWritten, nCount, GetLastError() );
hb_gtWriteCon( buf, strlen( buf ) );
}

It should show on the screen the exact result of WriteFile() function
executed before. Please send them here.
BTW I hope that it's not result of some quotas or other limits which
reduce maximum size of storage device area available for application.

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

>> PC> So 1-st thing you can try is changing in src/rtl/filesys.c all (6) lines
>> PC> with:
>> PC> if( hb_iswinnt() )
>> PC> to:
>> PC> if( hb_iswinnt() || hb_iswince() )
>> PC> Then rebuild Harbour for WinCE and repeat your test.
>> Done, but the same error occur in the same place.

PC> Anyhow good to know that we can use MT safe atomic read/write and
PC> seek operations for this WinCE. We should update filesys.c code.

PC> [...]

>> Done, but the same error occur in the same place.
>> What else can I try?

PC> So let's check what is the exact error.
PC> Add to modified filesys.c at line 1916, just after:
PC> nWritten = dwWritten;
PC> this code:
PC> {
PC> char buf[1024];
PC> hb_snprintf( buf, sizeof( buf ),
PC> "\r\n[dwWritten=%lu, nCount=%lu, error=%lu]\r\n",
PC> dwWritten, nCount, GetLastError() );
PC> hb_gtWriteCon( buf, strlen( buf ) );
PC> }

PC> It should show on the screen the exact result of WriteFile() function
PC> executed before. Please send them here.

See in attachment

PC> BTW I hope that it's not result of some quotas or other limits which
PC> reduce maximum size of storage device area available for application.

I'm doing these tests on PDAs with WM5 and WM6.5 and on one PC with
emulators - on WM5 (PDA) and WM2003 (PC em.) all is ok,
on WM6 (PC em.) and WM6.5(PDA and PC em.) i get this error.
So i don't think that is matter of physical memory.

Thanks for your help and time.

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Wed, 22 Dec 2010, Jaroslaw Kadziola wrote:

Hi Jarek,

> PC> It should show on the screen the exact result of WriteFile() function

> PC> executed before. Please send them here.
> See in attachment

Fine, so the problem is inside WriteFile() as expected.
Now simpler test without RDD:

proc main()
local i, h, n1, n2
? "test1"
h:=fcreate("_tst1.dat")
n1:=32
for i:=1 to 1024
n2:=fwrite(h,space(n1))
if n1!=n2 .or. i == 30
? str(i,4), str(n1,5), str(n2,5), h, str(i*32,5)
if inkey(10) != 13
exit
endif
endif
next
fclose(h)
? "test2"
for i:=1 to 1024
h:=fcreate("_tst2.dat")
n1:=i*32
n2:=fwrite(h,space(n1))
fclose(h)
if n1!=n2
? str(i,4), str(n1,5), str(n2,5), h
if inkey(10) != 13
exit
endif
endif
next
wait
return

Please check it and send the results.

> PC> BTW I hope that it's not result of some quotas or other limits which
> PC> reduce maximum size of storage device area available for application.
> I'm doing these tests on PDAs with WM5 and WM6.5 and on one PC with
> emulators - on WM5 (PDA) and WM2003 (PC em.) all is ok,
> on WM6 (PC em.) and WM6.5(PDA and PC em.) i get this error.
> So i don't think that is matter of physical memory.

I was not talking about physical memory but rather system settings
which limits disk/sd memory for the process or user like quota in *nixes.
Maybe they are enabled by default for some security reasons.

best regards,
Przemek

[Jaroslaw Kadziola]

Witam,

W li�cie datowanym 22 grudnia 2010 (13:36:26) mo�na przeczyta�:

PC> On Wed, 22 Dec 2010, Jaroslaw Kadziola wrote:

PC> Hi Jarek,

>> PC> It should show on the screen the exact result of WriteFile() function
>> PC> executed before. Please send them here.
>> See in attachment

PC> Fine, so the problem is inside WriteFile() as expected.
PC> Now simpler test without RDD:

PC> proc main()
PC> local i, h, n1, n2
PC> ? "test1"
PC> h:=fcreate("_tst1.dat")
PC> n1:=32
PC> for i:=1 to 1024
PC> n2:=fwrite(h,space(n1))
PC> if n1!=n2 .or. i == 30
PC> ? str(i,4), str(n1,5), str(n2,5), h, str(i*32,5)
PC> if inkey(10) != 13
PC> exit
PC> endif
PC> endif
PC> next
PC> fclose(h)
PC> ? "test2"
PC> for i:=1 to 1024
PC> h:=fcreate("_tst2.dat")
PC> n1:=i*32
PC> n2:=fwrite(h,space(n1))
PC> fclose(h)
PC> if n1!=n2
PC> ? str(i,4), str(n1,5), str(n2,5), h
PC> if inkey(10) != 13
PC> exit
PC> endif
PC> endif
PC> next
PC> wait
PC> return

PC> Please check it and send the results.

See in attachment.

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Wed, 22 Dec 2010, Jaroslaw Kadziola wrote:
> PC> proc main()
> PC> local i, h, n1, n2
> PC> ? "test1"
> PC> h:=fcreate("_tst1.dat")
> PC> n1:=32
> PC> for i:=1 to 1024
> PC> n2:=fwrite(h,space(n1))
> PC> if n1!=n2 .or. i == 30

Ups, sorry, please remove above ' .or. i == 30', it should be:
if n1!=n2
and repeat the test.

best regards,
Przemek

[Jaroslaw Kadziola]

Witam,

W li�cie datowanym 22 grudnia 2010 (14:15:29) mo�na przeczyta�:

PC> On Wed, 22 Dec 2010, Jaroslaw Kadziola wrote:
>> PC> proc main()
>> PC> local i, h, n1, n2
>> PC> ? "test1"
>> PC> h:=fcreate("_tst1.dat")
>> PC> n1:=32
>> PC> for i:=1 to 1024
>> PC> n2:=fwrite(h,space(n1))
>> PC> if n1!=n2 .or. i == 30

PC> Ups, sorry, please remove above ' .or. i == 30', it should be:
PC> if n1!=n2
PC> and repeat the test.

See in attachment

BTW on PDA with WM5 i get :

test1
test2
Press any..........

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Wed, 22 Dec 2010, Jaroslaw Kadziola wrote:

Hi,

> See in attachment
> BTW on PDA with WM5 i get :
> test1
> test2
> Press any..........

Fine. So we have an answer.
In some WinCE versions on some devices WriteFile() is limited and
accepts only some small buffers.
In your case it's 20480 bytes (0x5000).
Now we have few questions:
1. Is it possible to eliminate this limit by some system settings?
2. Short session with google shows that people reported such
problem with for different WinCE/Mobile versions and languages
so maybe some system patches exists or maybe MS documented it
somewhere with some suggested workarounds.
3. How to detect that such limits exists in given configuration
(WinCE/Mobile version, type of store age device, etc.) and
what is the limit value. Your earlier tests shows that it's
different in different installations. BTW try to increase
number of loops from 1024 to 8192 in the test I sent and
repeat it on PDA WM5.

I can add hack which will replace single WriteFile() call with
series of WriteFile() calls with smaller buffer and this is probably
sufficient workaround. But it reduce the performance, we still do
not know the maximum accepted buffer size for given configuration
(I'd have to add some function to set such limit by user) and
it's possible that it's completely useless because there are know
fixes public by MS.
So before I'll touch the code I would like to ask users interested
in WinCE port to look for information about this problem and suggested
by MS solutions. The problem can be exploited in some configuration by
any code using large enough buffer passed to WriteFile() function. In
such case nothing is written and GetLastError() returns:
ERROR_INVALID_PARAMETER (dec=87, hex=0x57)

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

PC> Fine. So we have an answer.
PC> In some WinCE versions on some devices WriteFile() is limited and
PC> accepts only some small buffers.
PC> In your case it's 20480 bytes (0x5000).
PC> Now we have few questions:
PC> 1. Is it possible to eliminate this limit by some system settings?
PC> 2. Short session with google shows that people reported such
PC> problem with for different WinCE/Mobile versions and languages
PC> so maybe some system patches exists or maybe MS documented it
PC> somewhere with some suggested workarounds.
PC> 3. How to detect that such limits exists in given configuration
PC> (WinCE/Mobile version, type of store age device, etc.) and
PC> what is the limit value. Your earlier tests shows that it's
PC> different in different installations. BTW try to increase
PC> number of loops from 1024 to 8192 in the test I sent and
PC> repeat it on PDA WM5.

The same as previously :
test1
test2
Press...

PC> I can add hack which will replace single WriteFile() call with
PC> series of WriteFile() calls with smaller buffer and this is probably
PC> sufficient workaround. But it reduce the performance, we still do
PC> not know the maximum accepted buffer size for given configuration
PC> (I'd have to add some function to set such limit by user) and
PC> it's possible that it's completely useless because there are know
PC> fixes public by MS.
PC> So before I'll touch the code I would like to ask users interested
PC> in WinCE port to look for information about this problem and suggested
PC> by MS solutions. The problem can be exploited in some configuration by
PC> any code using large enough buffer passed to WriteFile() function. In
PC> such case nothing is written and GetLastError() returns:
PC> ERROR_INVALID_PARAMETER (dec=87, hex=0x57)

Admit that I care about this because of irregularities in the operation of my
application on PDAs with systems newer than WM5. A small application was written
using FWPPC, therefore I hope that Antonio Linares reads this thread and can
help us get a solution.

Thanks a lot for your help and time.

--
Regards,
Jaroslaw Kadziola

[Jaroslaw Kadziola]

Hi Przemek,

Therefore , i have another question:
whether the issue with WriteFile() can generate false error messages
with databases when i want to open them?
(CORRUPTION DETECTED, WRITE ERROR, READ ERROR, etc.)

TIA

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Thu, 23 Dec 2010, Jaroslaw Kadziola wrote:

Hi Jarek,

> Therefore , i have another question:
> whether the issue with WriteFile() can generate false error messages
> with databases when i want to open them?
> (CORRUPTION DETECTED, WRITE ERROR, READ ERROR, etc.)

Two possible reasons:
1. The DBF file is corrupted because it was created by code
executing broken WriteFile()
2. ReadFile() windows API function has very similar problem
as WriteFile()

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

>> Therefore , i have another question:
>> whether the issue with WriteFile() can generate false error messages
>> with databases when i want to open them?
>> (CORRUPTION DETECTED, WRITE ERROR, READ ERROR, etc.)

> Two possible reasons:
> 1. The DBF file is corrupted because it was created by code
> executing broken WriteFile()

> 2. ReadFile() windows API function has very similar problem
> as WriteFile()

In this case database is not corrupted - finally i can to open it but there's no rule. Is there a chance to try to solve, as you wrote in previous posts?

Marry Christmas to You and all .

Regards,
Jaroslaw Kadziola

[Jarosław Kądzioła]

Hi Przemek,

>> Therefore , i have another question:
>> whether the issue with WriteFile() can generate false error messages
>> with databases when i want to open them?
>> (CORRUPTION DETECTED, WRITE ERROR, READ ERROR, etc.)

> Two possible reasons:
> 1. The DBF file is corrupted because it was created by code
> executing broken WriteFile()
> 2. ReadFile() windows API function has very similar problem
> as WriteFile()

If you find some time to return to the matter contained in this thread i'm ready to perform tests.

TIA

--
Regards,
Jaroslaw Ksdziola

[Przemysław Czerpak]

On Fri, 07 Jan 2011, Jarosław Kądzioła wrote:

Hi Jarek,

> > Two possible reasons:
> > 1. The DBF file is corrupted because it was created by code
> > executing broken WriteFile()
> > 2. ReadFile() windows API function has very similar problem
> > as WriteFile()
> If you find some time to return to the matter contained in this
> thread i'm ready to perform tests.

I'm still very busy but it's quite simple modification which allows
to make some test so I've just committed it.
Please take current SVN code with this modification:

2011-01-08 03:27 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

and rebuild Harbour for WinCE/MB with this macro:
HB_WIN_IOWRITE_LIMIT=0x5000
i.e.:
HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x5000
then try to create some DBF files. Check if they are correct.
If necessary you can experiment with smaller limit, i.e. 0x4000.
If also read operation is limited and newly created files are
correct but cannot be open by WinCE applications then please
try to make some tests with HB_WIN_IOREAD_LIMIT too, i.e.:
HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x4000 -DHB_WIN_IOREAD_LIMIT=0x4000

best reagards
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

Thanks a lot for quick answer.
I'll be perform tests ASAP.

Thanks again.

--
Regards,,
Jaroslaw Kadziola

[Jaroslaw Kadziola]

Hi Przemek,

>> > Two possible reasons:
>> > 1. The DBF file is corrupted because it was created by code
>> > executing broken WriteFile()
>> > 2. ReadFile() windows API function has very similar problem
>> > as WriteFile()
>> If you find some time to return to the matter contained in this
>> thread i'm ready to perform tests.

PC> I'm still very busy but it's quite simple modification which allows
PC> to make some test so I've just committed it.
PC> Please take current SVN code with this modification:

PC> 2011-01-08 03:27 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

PC> and rebuild Harbour for WinCE/MB with this macro:
PC> HB_WIN_IOWRITE_LIMIT=0x5000
PC> i.e.:
PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x5000
PC> then try to create some DBF files. Check if they are correct.
PC> If necessary you can experiment with smaller limit, i.e. 0x4000.
PC> If also read operation is limited and newly created files are
PC> correct but cannot be open by WinCE applications then please
PC> try to make some tests with HB_WIN_IOREAD_LIMIT too, i.e.:
PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x4000 -DHB_WIN_IOREAD_LIMIT=0x4000

Performed 6 tests with different settings flags (from 0x2000 to 0x7000).
Unfortunately, the results are not good. Only for value equal to 0x5000
test given by you (*) goes positive, while for any value of the flags was
not created the correct database (tested for WM6 and WM5).

Any other advices ?
TIA

(*)
proc main()

local i, h, n1, n2

? "test1"
h:=fcreate("_tst1.dat")
n1:=32

for i:=1 to 1024

n2:=fwrite(h,space(n1))
if n1!=n2

? str(i,4), str(n1,5), str(n2,5), h, str(i*32,5)

if inkey(10) != 13
exit
endif
endif
next
fclose(h)
? "test2"

for i:=1 to 1024

h:=fcreate("_tst2.dat")
n1:=i*32
n2:=fwrite(h,space(n1))
fclose(h)
if n1!=n2

? str(i,4), str(n1,5), str(n2,5), h

if inkey(10) != 13
exit
endif
endif
next
wait
return

--
Regards,
Jaroslaw Kadziola

[Jaroslaw Kadziola]

Hi Przemek,

I know ,that you are very busy but ...
is there any chance to return to this topic?

[Massimo Belgrano]

Hi Jaroslaw 

If you are  Able to run   a VM run Windows Mobile Device ROMs or OS builds with  VMWare/virtual BOx /qemu then you can share with it Przemek  that is able to test and run directly

Have samebody tried run window ce from linux?

My link for possible solution

2011/1/13 Jaroslaw Kadziola <kadz...@tlen.pl>

--
Massimo Belgrano

[Massimo Belgrano]

anso This link can be usefull;
Mobile Emulators & Simulators: The Ultimate Guide
http://www.mobilexweb.com/emulators

On 13 Gen, 15:40, Massimo Belgrano <mbelgr...@deltain.it> wrote:
> Hi Jaroslaw
> If you are  Able to run   a VM run Windows Mobile Device ROMs or OS builds
> with  VMWare/virtual BOx /qemu then you can share with it Przemek  that is
> able to test and run directly
> Have samebody tried run window

> ce<http://www.google.it/search?sourceid=chrome&ie=UTF-8&q=windows+ce+iso...>

> from
> linux?
>
> My link for possible

> solution<http://social.msdn.microsoft.com/Forums/en-GB/winembplatdev/thread/c4...>
>
> 2011/1/13 Jaroslaw Kadziola <kadzi...@tlen.pl>

[Przemysław Czerpak]

On Wed, 12 Jan 2011, Jaroslaw Kadziola wrote:

Hi Jarek,

> Performed 6 tests with different settings flags (from 0x2000 to 0x7000).

> Unfortunately, the results are not good. Only for value equal to 0x5000
> test given by you (*) goes positive, while for any value of the flags was
> not created the correct database (tested for WM6 and WM5).
> Any other advices ?

Interesting.
Please try to use some smaller value, i.e. compile Harbour with:

HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000

or even:

HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x200

and check the results the same (*) test.

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

>> Performed 6 tests with different settings flags (from 0x2000 to 0x7000).
>> Unfortunately, the results are not good. Only for value equal to 0x5000
>> test given by you (*) goes positive, while for any value of the flags was
>> not created the correct database (tested for WM6 and WM5).
>> Any other advices ?

PC> Interesting.
PC> Please try to use some smaller value, i.e. compile Harbour with:

PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000

PC> or even:

PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x200

PC> and check the results the same (*) test.

Test passed OK , but can't create the correct database
(for 0x1000 and 0x200).

--
Regards,
Jaroslaw Kadziola

[Jaroslaw Kadziola]

Hi Massimo,

MB> anso This link can be usefull;
MB> Mobile Emulators & Simulators: The Ultimate Guide
MB> http://www.mobilexweb.com/emulators

Thanks for this useful links.

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Fri, 14 Jan 2011, Jaroslaw Kadziola wrote:

Hi Jarek,

> PC> Please try to use some smaller value, i.e. compile Harbour with:

> PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000
> PC> or even:
> PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x200
> PC> and check the results the same (*) test.
> Test passed OK , but can't create the correct database
> (for 0x1000 and 0x200).

So probably the problem can be exploited by offset alignment, i.e.:

proc main()
local h:=fcreate( "_tst" )
? h
? fwrite( h, space( 10 ) ), ferror()
? fwrite( h, space( 0x5000 ) ), ferror()
fclose( h )
wuat
return

BTW do you have any errors when new table is created by dbCreate()

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

>> PC> Please try to use some smaller value, i.e. compile Harbour with:
>> PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000
>> PC> or even:
>> PC> HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x200
>> PC> and check the results the same (*) test.
>> Test passed OK , but can't create the correct database
>> (for 0x1000 and 0x200).

> So probably the problem can be exploited by offset alignment, i.e.:

> proc main()
> local h:=fcreate( "_tst" )
> ? h
> ? fwrite( h, space( 10 ) ), ferror()
> ? fwrite( h, space( 0x5000 ) ), ferror()
> fclose( h )
> wuat
> return

See in attached files.

> BTW do you have any errors when new table is created by dbCreate()

No, only when trying open.

Thanks for Your help and time.

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Fri, 14 Jan 2011, Jaroslaw Kadziola wrote:

Hi Jarek,

> See in attached files.

Thx, both seems to work correctly.

> > BTW do you have any errors when new table is created by dbCreate()
> No, only when trying open.

So maybe write operations are already fixed and the problem is with read
ones. What it the error when you are opening them?
Can you send such newly created DBF files here?
Can you check WinCE build compiled with:
set HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000 -DHB_WIN_IOREAD_LIMIT=0x1000

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

PC> Hi Jarek,

>> See in attached files.

PC> Thx, both seems to work correctly.

>> > BTW do you have any errors when new table is created by dbCreate()
>> No, only when trying open.

PC> So maybe write operations are already fixed and the problem is with read
PC> ones.What it the error when you are opening them?

I think that the fault is on both sides (WRITE and READ), because during
my test the error pops up "Write Error" (with a sufficiently large number of fields)
and the creation of index files larger database (more than a dozen records),
these index files are not valid .
On the other hand, when trying open a database, i get a false message about
corrupted database (CORRUPTION DETECTED),but this database is not corrupted.

PC> Can you send such newly created DBF files here?

Attached dbf and ntx files.

PC> Can you check WinCE build compiled with:
PC> set HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000 -DHB_WIN_IOREAD_LIMIT=0x1000

The same as previously databases are non-databases but Your test done
ok.

--
Regards,
Jaroslaw Kadziola

[Jaroslaw Kadziola]

Hi Przemek,

PC>> Hi Jarek,

>>> See in attached files.

PC>> Thx, both seems to work correctly.

>>> > BTW do you have any errors when new table is created by dbCreate()
>>> No, only when trying open.

PC>> So maybe write operations are already fixed and the problem is with read
PC>> ones.What it the error when you are opening them?

JK> I think that the fault is on both sides (WRITE and READ), because during
JK> my test the error pops up "Write Error" (with a sufficiently large number of fields)
JK> and the creation of index files larger database (more than a dozen records),
JK> these index files are not valid .
JK> On the other hand, when trying open a database, i get a false message about
JK> corrupted database (CORRUPTION DETECTED),but this database is not corrupted.

PC>> Can you send such newly created DBF files here?

JK> Attached dbf and ntx files.

PC>> Can you check WinCE build compiled with:
PC>> set HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000 -DHB_WIN_IOREAD_LIMIT=0x1000

JK> The same as previously databases are non-databases but Your test done
JK> ok.

Is there any chance for any further steps in this topic?

[Przemysław Czerpak]

On Wed, 19 Jan 2011, Jaroslaw Kadziola wrote:

Hi Jarek,

> PC>> Can you send such newly created DBF files here?

> JK> Attached dbf and ntx files.
> PC>> Can you check WinCE build compiled with:
> PC>> set HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000 -DHB_WIN_IOREAD_LIMIT=0x1000
> JK> The same as previously databases are non-databases but Your test done
> JK> ok.
> Is there any chance for any further steps in this topic?

I've checked the files you sent and both (.dbf and .ntx) are corrupted at
the beginning of file. It looks that the low level device driver used
for storage device in your WM installations is broken and does not work
correctly on sequential write.
Can you check if you can copy some bigger DBF file with a lot of
fields and long records to your mobile device and then try to open
if and browse from Harbour WinCE application. Try to use Harbour
compiled without any HB_WIN_IOREAD_LIMIT so we can check if read
operations works and the problem is only with write.
BTW how do you copy files to your WinME device?

best regards,
Przemek

[Jaroslaw Kadziola]

Witam,

W li�cie datowanym 19 stycznia 2011 (16:06:49) mo�na przeczyta�:

PC> On Wed, 19 Jan 2011, Jaroslaw Kadziola wrote:

PC> Hi Jarek,

>> PC>> Can you send such newly created DBF files here?
>> JK> Attached dbf and ntx files.
>> PC>> Can you check WinCE build compiled with:
>> PC>> set HB_USER_CFLAGS=-DHB_WIN_IOWRITE_LIMIT=0x1000 -DHB_WIN_IOREAD_LIMIT=0x1000
>> JK> The same as previously databases are non-databases but Your test done
>> JK> ok.
>> Is there any chance for any further steps in this topic?

PC> I've checked the files you sent and both (.dbf and .ntx) are corrupted at
PC> the beginning of file. It looks that the low level device driver used
PC> for storage device in your WM installations is broken and does not work
PC> correctly on sequential write.
PC> Can you check if you can copy some bigger DBF file with a lot of
PC> fields and long records to your mobile device and then try to open
PC> if and browse from Harbour WinCE application. Try to use Harbour
PC> compiled without any HB_WIN_IOREAD_LIMIT

Done.
I used database, which does not have any problems reading and i added
to it a couple of 'long' fields (C 115).
When trying to open i received an error (Read Error - DOS Error 87).
In another variant after deleting few fields when trying add records
using APPEND FROM i get (Write Error - DOS Error 87).

I'll just add a reminder that all of these problems occur on devices
running WM6 and WM6.5 but also on the emulator WM6 and WM6.5.
On devices running WM5 and emulators WM2003 and WM5 everything goes ok.

PC> so we can check if read
PC> operations works and the problem is only with write.

From my observation is that the fault lies on both sides.
I have written about this repeatedly, that there are errors that
are false alarms - for example CORRUPTION DETECTED or READ ERROR - which points
to a failure to read, but also write errors with creating bigger databases or indexes.
Bigger mean more fields not more records.

PC> BTW how do you copy files to your WinME device?

By using ActiveSync or via FTP, but in my application above all
through the dbCreate().

Thanks for Your time and help.

--
Regards,
Jaroslaw Kadziola

[Jarosław Kądzioła]

Hi Przemek,

Sorry that i repeat myself, but...is there any chance for

any further steps in this topic?

TIA

--
Regards,
Jaroslaw Ksdziola

[Viktor Szakáts]

Sorry that i repeat myself, but...is there any chance for

any further steps in this topic?

IMO it'd be nice to hear from other users using Harbour on 

Windows Mobile 6 or 6.5, wether they experience similar 

errors, or do they work okay with .dbf files on these systems.

Next step would be to assemble small test program which 

doesn't use Harbour at all, to demonstrate the problem. If 

such demonstration is ready, it can be directly reported to 

MS for information and fix.

If it's only your system, it may well be some build problem, 

wce compiler toolchain problem (f.e. wrongly mixed WM 

SDK headers, wrongly setup mingwarm) or something else 

local.

So:

1) anyone running .dbf handling OK on WM6 or WM6.5?

2) Is there a self-contained pure .c demonstration of the 

    problem?

Viktor

[Jaroslaw Kadziola]

Hi Viktor ,

Thank you for your interest.

VS> If it's only your system, it may well be some build problem,
VS> wce compiler toolchain problem (f.e. wrongly mixed WM
VS> SDK headers, wrongly setup mingwarm) or something else
VS> local.

All tests recommended by Przemek and my sample and my application's
behavior i described in current thread and here :

[harbour] Big problem with harbour-wince Thu, 02 Dec 2010 12:25:33 +0100

and here on FWPPC forum:
http://forums.fivetechsupport.com/viewtopic.php?f=4&t=20444

I don't think that this is a matter of configuring my system - i compile
programs on several different machines and the result is always the
same, the more that on the older systems (WM5, WM2003) everything
works ok.

VS>Next step would be to assemble small test program which
VS>doesn't use Harbour at all, to demonstrate the problem. If
VS>such demonstration is ready, it can be directly reported to
VS>MS for information and fix.

That is exactly what i need and i look forward to this,
because myself i can't write a test program in a form
that would which will explain this problem so i can only
count on your help (professionals like you and Przemek).

Thanks again for your interest.

--
Regards,
Jaroslaw Kadziola

[Viktor Szakáts]

VS> If it's only your system, it may well be some build problem,
VS> wce compiler toolchain problem (f.e. wrongly mixed WM
VS> SDK headers, wrongly setup mingwarm) or something else
VS> local.


All tests recommended by Przemek and my sample and my application's
behavior i described in current thread and here :

[harbour] Big problem with harbour-wince Thu, 02 Dec 2010 12:25:33 +0100

and here on FWPPC forum:
http://forums.fivetechsupport.com/viewtopic.php?f=4&t=20444

I've followed the threads on this list. Anyhow it stays 

true that a standalone .c test would be required. I don't 

know if it has been done yet, if not it should be done to 

demonstrate the problem to MS and sort out Harbour 

(which don't seem at fault at all).

BTW, on linked thread I see only your own bug report.

I don't think that this is a matter of configuring my system - i compile
programs on several different machines and the result is always the

Anyhow it's worth a try. F.e. ask someone else to create 

the test app for you, or speak with other WM6, WM6.5 users 

to repeat the problem on their systems, with their tools.

Better also test it with mingwarm (possibly on *nix cross-build, 

and multiple win versions, msvcarm multiple version on 

multiple machines)

It will help narrow down where the problem is.

 

same, the more that on the older systems (WM5, WM2003) everything
works ok.

Unfortunately, the latter is not proof for anything.

VS>Next step would be to assemble small test program which
VS>doesn't use Harbour at all, to demonstrate the problem. If
VS>such demonstration is ready, it can be directly reported to
VS>MS for information and fix.

That is exactly what i need and i look forward to this,
because myself i can't write a test program in a form
that would which will explain this problem so i can only
count on your help (professionals like you and Przemek).

In the meantime you may also search places like Stack Overflow

and other places to see if anybody else have experienced 

the same problem. It seems so huge problem (if it isn't 

something local), that it must be some signs of it on the internet.

At the end there can be three results:

- It's an MS bug. In this case MS should be requested to 

  fix it. Adding workarounds to Harbour doesn't seem possible, 

  and it's not very good solution anyways. In this case there 

  must be reports on the internet.

- It's an environment bug. Nothing needs to be done on our side.

  This can be confirmed by redoing existing tests on other 

  configs.

- It's a Harbour bug.

   a) in source code. This is doubtful.

   b) in build configuration. This is theoretically possible (f.e. some of the 

      zillion #defines for wce is missing or not properly set for 

      your specific config and it creates such problem.)

      For this we need .c sample which works OK, and compare 

      its build method with our build.

Viktor

[Przemysław Czerpak]

On Wed, 26 Jan 2011, Jaroslaw Kadziola wrote:

Hi,

> VS>Next step would be to assemble small test program which
> VS>doesn't use Harbour at all, to demonstrate the problem. If
> VS>such demonstration is ready, it can be directly reported to
> VS>MS for information and fix.
> That is exactly what i need and i look forward to this,
> because myself i can't write a test program in a form
> that would which will explain this problem so i can only
> count on your help (professionals like you and Przemek).

AFAIR this PRG code fails on your machine:

proc main()
local h
h:=fcreate("_tst.dat")
? fwrite(h,space(20512))
? ferror()
fclose(h)
return

If I'm right then C code below should fail too.
Can you check?

best regards,
Przemek

#include <windows.h>

#define FILE_NAME TEXT( "_tst.dat" )
#define FILE_SIZE 20512

int main( void )
{
HANDLE hFile;

hFile = CreateFile( FILE_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );

if( hFile != ( HANDLE ) INVALID_HANDLE_VALUE )
{
DWORD dwWritten, dwError;
BOOL fResult;
BYTE buff[ FILE_SIZE ];
TCHAR msg[ 1024 ];

memset( buff, ' ', FILE_SIZE );
fResult = WriteFile( hFile, buff, FILE_SIZE, &dwWritten, NULL );
dwError = fResult ? 0 : GetLastError();
CloseHandle( hFile );
wsprintf( msg,
TEXT( "WriteFile(...%d...)->%ld, written=%ld, error=%ld" ),
FILE_SIZE, fResult, dwWritten, dwError );
MessageBox( NULL, msg, FILE_NAME, 0 );
}
else
{
MessageBox( NULL, TEXT( "Cannot create file: '" )
FILE_NAME TEXT( "'" ), NULL, 0 );
}
return 0;
}

[Jaroslaw Kadziola]

Hi,

>> VS>Next step would be to assemble small test program which
>> VS>doesn't use Harbour at all, to demonstrate the problem. If
>> VS>such demonstration is ready, it can be directly reported to
>> VS>MS for information and fix.
>> That is exactly what i need and i look forward to this,
>> because myself i can't write a test program in a form
>> that would which will explain this problem so i can only
>> count on your help (professionals like you and Przemek).

PC> AFAIR this PRG code fails on your machine:

PC> proc main()
PC> local h
PC> h:=fcreate("_tst.dat")
PC> ? fwrite(h,space(20512))
PC> ? ferror()
PC> fclose(h)
PC> return

See in Screen58.jpg

PC> If I'm right then C code below should fail too.
PC> Can you check?

PC> #include <windows.h>

PC> #define FILE_NAME TEXT( "_tst.dat" )
PC> #define FILE_SIZE 20512

PC> int main( void )
PC> {
PC> HANDLE hFile;

PC> hFile = CreateFile( FILE_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,
PC> CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );

PC> if( hFile != ( HANDLE ) INVALID_HANDLE_VALUE )
PC> {
PC> DWORD dwWritten, dwError;
PC> BOOL fResult;
PC> BYTE buff[ FILE_SIZE ];
PC> TCHAR msg[ 1024 ];

PC> memset( buff, ' ', FILE_SIZE );
PC> fResult = WriteFile( hFile, buff, FILE_SIZE, &dwWritten, NULL );
PC> dwError = fResult ? 0 : GetLastError();
PC> CloseHandle( hFile );
PC> wsprintf( msg,
PC> TEXT( "WriteFile(...%d...)->%ld, written=%ld, error=%ld" ),
PC> FILE_SIZE, fResult, dwWritten, dwError );
PC> MessageBox( NULL, msg, FILE_NAME, 0 );
PC> }
PC> else
PC> {
PC> MessageBox( NULL, TEXT( "Cannot create file: '" )
PC> FILE_NAME TEXT( "'" ), NULL, 0 );
PC> }
PC> return 0;
PC> }

See in Screen59.jpg

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Wed, 26 Jan 2011, Jaroslaw Kadziola wrote:

Hi,

> See in Screen58.jpg
> See in Screen59.jpg

So now both stop to fail.
This test was a part of test I sent to you few day ago:

proc main()
local i, h, n1, n2

? "test2"
for i:=1 to 1024
h:=fcreate("_tst2.dat")
n1:=i*32
n2:=fwrite(h,space(n1))
fclose(h)
if n1!=n2
? str(i,4), str(n1,5), str(n2,5), h
if inkey(10) != 13
exit
endif
endif
next
wait
return

Does this code still fails for you?
What happens if you change:

for i:=1 to 1024

to:
for i:=641 to 1024

BTW do you use unmodified Harbour compiled without any
HB_WIN_IO*_LIMIT?

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

PC> On Wed, 26 Jan 2011, Jaroslaw Kadziola wrote:

PC> Hi,

>> See in Screen58.jpg
>> See in Screen59.jpg

PC> So now both stop to fail.
PC> This test was a part of test I sent to you few day ago:

PC> proc main()
PC> local i, h, n1, n2
PC> ? "test2"
PC> for i:=1 to 1024
PC> h:=fcreate("_tst2.dat")
PC> n1:=i*32
PC> n2:=fwrite(h,space(n1))
PC> fclose(h)
PC> if n1!=n2
PC> ? str(i,4), str(n1,5), str(n2,5), h
PC> if inkey(10) != 13
PC> exit
PC> endif
PC> endif
PC> next
PC> wait
PC> return

PC> Does this code still fails for you?
Yes, see in screen60.jpg

PC> What happens if you change:
PC> for i:=1 to 1024
PC> to:
PC> for i:=641 to 1024

See in screen61.jpg

PC> BTW do you use unmodified Harbour compiled without any
PC> HB_WIN_IO*_LIMIT?

Yes

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Wed, 26 Jan 2011, Jaroslaw Kadziola wrote:

Hi Jarek,

> PC> On Wed, 26 Jan 2011, Jaroslaw Kadziola wrote:
> PC> proc main()
> PC> local i, h, n1, n2
> PC> ? "test2"
> PC> for i:=1 to 1024
> PC> h:=fcreate("_tst2.dat")
> PC> n1:=i*32
> PC> n2:=fwrite(h,space(n1))
> PC> fclose(h)
> PC> if n1!=n2
> PC> ? str(i,4), str(n1,5), str(n2,5), h
> PC> if inkey(10) != 13
> PC> exit
> PC> endif
> PC> endif
> PC> next
> PC> wait
> PC> return
> PC> Does this code still fails for you?
> Yes, see in screen60.jpg

This is not the same test. On the screen60.jpg I can see
"test1" so it means that you executed previous code.

> PC> What happens if you change:
> PC> for i:=1 to 1024
> PC> to:
> PC> for i:=641 to 1024
> See in screen61.jpg

Same as above. Previous code executed.

Please run exactly what I asked. It's possible that
the problem can be exploited only by series of some write
operations and when you change the tests I cannot create
reduced example.

Please try this code:

proc main()

local i, h, n1, n2

? "test2"

for i:=1 to 1024

if h==NIL
? "starting at", hb_ntos(i)
endif

h:=fcreate("_tst2.dat")
n1:=i*32
n2:=fwrite(h,space(n1))
fclose(h)
if n1!=n2

? str(i,4), str(n1,5), str(n2,5), h

if inkey(10) != 13
exit
endif
endif
next
wait
return

and then modified version with:

for i:=641 to 1024

best regards,
Przemek

[Jarosław Kądzioła]

Hi Przemek,

Sorry for mistake - haste is a bad advisor.

> Please try this code:

See screen_001.jpg

> and then modified version with:
> for i:=641 to 1024

See screen_641.jpg

--
Regards,
Jaroslaw Kadziola

[Przemysław Czerpak]

On Wed, 26 Jan 2011, Jarosław Kądzioła wrote:

Hi Jarek,

> > proc main()
> > local i, h, n1, n2
> > ? "test2"
> > for i:=1 to 1024
> > if h==NIL
> > ? "starting at", hb_ntos(i)
> > endif
> > h:=fcreate("_tst2.dat")
> > n1:=i*32
> > n2:=fwrite(h,space(n1))
> > fclose(h)
> > if n1!=n2
> > ? str(i,4), str(n1,5), str(n2,5), h
> > if inkey(10) != 13
> > exit
> > endif
> > endif
> > next
> > wait
> > return
> See screen_001.jpg
> > and then modified version with:
> > for i:=641 to 1024
> See screen_641.jpg

So both failed at:
n2:=fwrite(h,space(641*32))

So why this does not fails?

proc main()
local h
h:=fcreate("_tst.dat")
? fwrite(h,space(20512))
? ferror()
fclose(h)
return

It makes exactly the same operation.
Maybe the problem can be exploited only when some space on storage
device is reused so it will fail too if you change "_tst.dat" to
"_tst2.dat"?
If it wont then I do not understand why the same code may fail in
one example but doesn't in second.

best regards,
Przemek

[Jaroslaw Kadziola]

Hi Przemek,

>> > proc main()
>> > local i, h, n1, n2
>> > ? "test2"
>> > for i:=1 to 1024
>> > if h==NIL
>> > ? "starting at", hb_ntos(i)
>> > endif
>> > h:=fcreate("_tst2.dat")
>> > n1:=i*32
>> > n2:=fwrite(h,space(n1))
>> > fclose(h)
>> > if n1!=n2
>> > ? str(i,4), str(n1,5), str(n2,5), h
>> > if inkey(10) != 13
>> > exit
>> > endif
>> > endif
>> > next
>> > wait
>> > return
>> See screen_001.jpg
>> > and then modified version with:
>> > for i:=641 to 1024
>> See screen_641.jpg

PC> So both failed at:
PC> n2:=fwrite(h,space(641*32))

PC> So why this does not fails?

PC> proc main()

PC> local h
PC> h:=fcreate("_tst.dat")
PC> ? fwrite(h,space(20512))
PC> ? ferror()
PC> fclose(h)
PC> return

PC> It makes exactly the same operation.
PC> Maybe the problem can be exploited only when some space on storage
PC> device is reused so it will fail too if you change "_tst.dat" to
PC> "_tst2.dat"?

Situation unchanged after renaming the files

PC> If it wont then I do not understand why the same code may fail in
PC> one example but doesn't in second.

So..if you do not understand what i have to say ? :)
But seriously are there other ways to solve this problem?
Maybe some other tests?

--
Regards,
Jaroslaw Kadziola

[Viktor Szakáts]

PC> It makes exactly the same operation.
PC> Maybe the problem can be exploited only when some space on storage
PC> device is reused so it will fail too if you change "_tst.dat" to
PC> "_tst2.dat"?

Situation unchanged after renaming the files

PC> If it wont then I do not understand why the same code may fail in
PC> one example but doesn't in second.

So..if you do not understand what i have to say ? :)
But seriously are there other ways to solve this problem?
Maybe some other tests?

Can it be some alignment requirements for the passed buffer?

Anyhow I think these tests must be repeated on another 

environment to sort it out from the equation. Pls find someone 

who is willing to repeat these tests on her own WM6.x machines 

with her own Harbour build.

Without this it's impossible to tell if this is local problem or 

something consistently happening on any WM6.x device.

Viktor

[Przemysław Czerpak]

On Thu, 27 Jan 2011, Jaroslaw Kadziola wrote:

Hi Jarek,

> >> > proc main()
> >> > local i, h, n1, n2
> >> > ? "test2"
> >> > for i:=1 to 1024
> >> > if h==NIL
> >> > ? "starting at", hb_ntos(i)
> >> > endif
> >> > h:=fcreate("_tst2.dat")
> >> > n1:=i*32
> >> > n2:=fwrite(h,space(n1))
> >> > fclose(h)
> >> > if n1!=n2
> >> > ? str(i,4), str(n1,5), str(n2,5), h
> >> > if inkey(10) != 13
> >> > exit
> >> > endif
> >> > endif
> >> > next
> >> > wait
> >> > return

> PC> So why this does not fails?
> PC> proc main()
> PC> local h
> PC> h:=fcreate("_tst.dat")
> PC> ? fwrite(h,space(20512))
> PC> ? ferror()
> PC> fclose(h)
> PC> return

> So..if you do not understand what i have to say ? :)
> But seriously are there other ways to solve this problem?
> Maybe some other tests?

Please try to reduce the first test checking how long the problem
is repeatable. I.e. change

for i:=641 to 1024

to:
for i:=641 to 641
If it still fails then replace
for i:=641 to 641
[...]
next
with:
i:=641
[...]
etc. Make it simpler and simpler until you end with the same code
as in second example.

best regards,
Przemek

[Przemysław Czerpak]

On Tue, 25 Jan 2011, Jarosław Kądzioła wrote:

Hi Jarek,

> Sorry that i repeat myself, but...is there any chance for

> any further steps in this topic?

Please make tests current SVN. It should be fixed.

best regards,
Przemek

[Jarosław Kądzioła]

Hi Przemek,

>> Sorry that i repeat myself, but...is there any chance for
>> any further steps in this topic?

> Please make tests current SVN. It should be fixed.

I'll try it ASAP, thanks a lot.

--
Regards,
Jaroslaw Kadziola