Reading MasmBasic files without pain

[HSE]

Hi all!

Some first step to change RTF colors.

Original idea was a minor customization of Masm64 SDK Help files, but take other direction for a while

Now is posible to read "asc" without have to suffer... backgrounds.

Regards, HSE.

Update n3: solved fail in color collection.
                 RichColors3.zip (27.12 kB - downloaded 31 times.)
Update n4: - read commandLine arguments (requiered to be used with "Open with" from File Explorer.
                 - full ObjAsm code

[jj2007]

Hi Hector,

I am not sure what you are trying to achieve... RTF files do have their own backgrounds, sometimes. Can you explain what exactly you want? White on black?

Besides, it does not load complete files, just a few lines. Why is that?

Attached an alternative version, with full source code. Drag any file (rtf, asc, asm, inc, ...) over the exe

(hint: the *.asc files open just fine in RichMasm; one of them even with a black background...)

[HSE]

Hi JJ!

I am not sure what you are trying to achieve...

To change some colors, without erase syntax or other colorization.

Besides, it does not load complete files, just a few lines. Why is that?

I think that was solved, but only process first 4092 bytes of stream  .

Attached an alternative version, with full source code.

An excelent example, I don't see code in *.asc, almost everything black.

Additionaly happen that some code I have in ObjAsm32 I never adapted to ObjAsm Fusion. I have to study a little that because Biterider added some options.

After reading just delete the Topic. I wil post again when I have time to see the problems.

HSE.

[jj2007]

Besides, it does not load complete files, just a few lines. Why is that?

I think that was solved, but only process first 4092 bytes of stream  .

Not yet solved, sorry... check what you return in the callback

Attached an alternative version, with full source code.

An excelent example, I don't see code in *.asc, almost everything black.

Yes indeed, the small source is all black, simply because you would have to edit it, changing the foreground colour to white. The second, bigger, source has been edited accordingly and looks fine. The problem is indeed the different behaviour of foreground and background colours.

[jj2007]

Here is an experimental version of RichMasm:
- load an asc or rtf file
- press Ctrl G, type udc=6 and hit Return
- press Ctrl A to select the whole text
- go to menu Edit & Format
- hold Ctrl and click Green

You lose all colours, but it will be white on black, so some of you guys might be happy

[HSE]

check what you return in the callback

That was the problem, I forget eax=0:

Code Select Expand

StreamOutProc2 proc hFile:DWORD,pBuffer:DWORD, NumBytes:DWORD, pBytesWritten:DWORD
mov eax, hFile
add eax, BytesWritten1  ; Global dword
                        ; must be 0 when message EM_STREAMOUT
mov hFile, eax
invoke MemClone, hFile, pBuffer, NumBytes
mov eax, BytesWritten1
add eax, NumBytes
mov BytesWritten1, eax
mov eax, 0
ret
StreamOutProc2 endp


Thanks 

[jj2007]

Hi Hector,

My callbacks typically look like this:

Code Select Expand

StreamRtf proc ; cookie, pBuffer, NumBytes, pBytesWritten
invoke RtlMoveMemory, [esp+12], [esp+12], [esp+12] ; dest, source, count
mov edx, [esp+16]
or dword ptr [edx], -1 ; return non-zero to pBytesWritten
xor eax, eax ; signal success to the RichEdit control
retn 4*4
StreamRtf endp

[HSE]

That look so smart! I will test that 

[jj2007]

This version is a whopping 6 bytes shorter - 23 instead of 29 bytes:

Code Select Expand

StreamRtf: ; cookie, pBuffer, NumBytes, pBytesWritten
.DATA?
retad dd ?
.CODE
pop retad
call RtlMoveMemory ; eat three args
pop edx ; #4
or dword ptr [edx], -1 ; return non-zero to pBytesWritten
xor eax, eax ; signal success to the RichEdit control
jmp retad ; return

Eight bytes shorter, i.e. 21 bytes:

Code Select Expand

StreamRtf: ; cookie, pBuffer, NumBytes, pBytesWritten
fild stack ; ret address to ST(0)
pop edx ; discard ret address
call RtlMoveMemory ; eat three args
pop edx ; #4
or dword ptr [edx], -1 ; return non-zero to pBytesWritten
xor eax, eax ; signal success to the RichEdit control
push eax ; create a slot for the ret address
fistp stack
retn

For the last one, you need some confidence in your FPU having one free slot, and RtlMoveMemory not using the FPU incorrectly

[HSE]

Apparently RtlMoveMemory is a very complex function that make all calculations I need to make for MemClone (wich is almost a wrapper to rep movsd and rep movsb).

CallBack always have in hFile (or cookie if you like) the same value: the beginning of file or buffer. 

[jj2007]

Proud owners of MasmBasic can do the callback in 15 bytes (MbCopy does not modify ecx):

Code Select Expand

StreamRtf: ; cookie, pBuffer, NumBytes, pBytesWritten
  pop ecx ; ret address
  call MbCopy ; eat three args
  pop edx ; #4
  or eax, -1
  mov [edx], eax ; return non-zero to pBytesWritten
  inc eax ; signal success to the RichEdit control
  jmp ecx ; return

[HSE]

Proud owners of MasmBasic can do the callback in 15 bytes (MbCopy does not modify ecx):

Proud owners only retrieve last split 

RichEdit split the content in pieces of 4092 bytes (or less last split, or if content is lower than 4092 bytes). Because "cookie" is always first position in buffer, each split overwrite previous stored split (except first, obviously) if you not recalculate storage position in the buffer. 

[jj2007]

Damnit, I knew something was wrong

OK, 31 bytes (the buffer must be big enough):

Code Select Expand

mov editstream.dwCookie, edi  ; pass the buffer
...
StreamToBuffer:
  pop ecx ; ret address
  pop eax ; destination passed by control
  add eax, StreamOutProcPos ; global variable
  push eax ; new destination
  call MbCopy ; eat three args
  pop edx ; #4, pBytesWritten
  mov eax, [esp-8] ; bytes copied
  add StreamOutProcPos, eax ; adjust counter for destination
  mov [edx], eax ; return non-zero to pBytesWritten
  xor eax, eax ; signal success to the RichEdit control
  jmp ecx ; return

[HSE]

 

[HSE]

Hi All!

Updated to open *.asc and *.rtf from File Explorer. That can work because now CommandLine arguments are readed.

Also source code added in first post.