This is too slow

[Antariy]

Frank, make this:

Code Select Expand


invoke GlobalAlloc,GMEM_MOVEABLE,DWORD PTR Lenght


to this

Code Select Expand


invoke GlobalAlloc,GMEM_MOVEABLE or GMEM_DDESHARE,DWORD PTR Lenght


Just for make sure  :lol

OK! Before posting the 100th release, I'll wait some hour. Better to test it before posting.  :P

I'm guess problem is not in DDESHARE flag, but if you set it and post it now, we can see results now :P

[frktons]

here it is.

[frktons]

Alex you are running Win XP pro sp2, the same OS as Dave's one.
What could be so different between your machines? Oex has the same problem, same OS,
I really don't understand.  ::)

[Antariy]

Alex you are running Win XP pro sp2, the same OS as Dave's one.
What could be so different between your machines? Oex has the same problem, same OS,

http://www.masm32.com/board/index.php?topic=15365.msg125844#msg125844 - a first thing which can be

[frktons]

You should search for the runtime dependency: maybe somewhere you did not preserve some register,
or you rely that this register have the same/specific value, etc.

I don't think so. Otherwise bad results should appear in many more systems. They show up only
in a few machines, when people probably compile with old MASM versions. A corrupted register
should break entire logic of PROC.

Something else in my opinion is working bad here.  ::)

[Antariy]

I don't think so. Otherwise bad results should appear in many more systems. They show up only
in a few machines, when people probably compile with old MASM versions. A corrupted register
should break entire logic of PROC.

All bugs is based on thing, that many of the equal systems has the same layout of things. So, this is very possible that most of machines have, for example, zero some register after some operation, etc. At equal sub-builds of the system this should be something as rule.

But this is only first supposition - no more than.

[frktons]

All bugs is based on thing, that many of the equal systems has the same layout of things. So, this is very possible that most of machines have, for example, zero some register after some operation, etc. At equal sub-builds of the system this should be something as rule.

But this is only first supposition - no more than.

Of course, but some bugs can depend on things you don't even suspect. Maybe an antivirus, or a system
program, or a corrupted dll. I hope it is only a program bug, because, if it is, we'll find it and correct it.
But if it is something related to OS, or dll, or any other thing, it could be very complex to get rid of it.

Let's see if the changes we've made produce some effect. Otherwise a debug session can help find
were the problem is.

[dedndave]

ok - it still has the problem
i am debugging it - i will figure it out   :U
it seems only logical to troubleshoot it on a system that exhibits the problem
it cannot be easily solved on a machine that doesn't   :bg

[frktons]

ok - it still has the problem
i am debugging it - i will figure it out   :U
it seems only logical to troubleshoot it on a system that exhibits the problem
it cannot be easily solved on a machine that doesn't   :bg

You are right, indeed.  :U

[Antariy]

Frank, this is culprit:

Code Select Expand


ProgData.inc:

AlgoDesc         BYTE  31 DUP (?)
AlgoDescSize     DWORD SIZEOF AlgoDesc

Algo1.asm:
AlgoDesc1        byte  "ustrv$ + GetNumberFormat      ",0 ; ZERO BYTE SHOULD BE REPLACED TO SPACE
...
invoke DisplayAt, dword ptr AlgoColDesc, dword ptr AlgoRow, addr AlgoDesc,
                     dword ptr AlgoDescSize


So, you are display a binary zero into screen, because SIZEOF is includes zero to the length of the string.
You can solve all that strings by:

Code Select Expand


AlgoDesc1        byte  "ustrv$ + GetNumberFormat       " ; one space added
or, if you want to have zero terminated string
AlgoDesc1        byte  "ustrv$ + GetNumberFormat       " ; one space added
db 0




Alex

[dedndave]

i haven't completely solved the problem
but - i have isolated it to some degree
there appears to be a null byte at that point in the text data


something else, not related to this specific problem ...

Code Select Expand

ConvertToDOS PROC DestBuffer:DWORD, SourceBuffer:DWORD


   mov  esi, SourceBuffer
   mov  edi, DestBuffer

   mov  ecx, CharNumber  ;shouldn't this be NumCycles ?????? - we do 2 chars per pass

[dedndave]

he may have found it   :U

[Antariy]

he may have found it   :U

:P  :lol

[dedndave]

well - i count 6 spaces at the end of that string
in the pasted text, i only count 5   :P

let me see if i can find it

[Antariy]

Even better:

Code Select Expand


invoke lstrlen,addr AlgoDesc
invoke DisplayAt, dword ptr AlgoColDesc, dword ptr AlgoRow, addr AlgoDesc,
                     eax




Alex