Recent posts

#11

The Campus / Re: Operand must be relocatabl...

Last post by 16bitPM - December 03, 2024, 10:58:33 PM

It's 16-bit code, because your code also was 16-bit, but it's actually also relevant for 32-bit ( most likely also for 64-bit ).

Well, well, well!!
Shall I make a bug fix request on Github?

#12

The Workshop / Re: Challenge: Hexify #s

Last post by jj2007 - December 03, 2024, 09:03:11 PM

what if the hex chars use lowercase "a-f" instead

a>A

#13

The Workshop / Re: Challenge: Hexify #s

Last post by NoCforMe - December 03, 2024, 08:38:29 PM

Also, JJ, something I noticed while coding my comma-delimiting code:
The buffer I got from my RichEdit control (using EM_GETTEXTEX) only had carriage returns (0Dh) with no line feeds (0Ah). Is this the way all (ASCII) text in a RichEdit control is encoded? I'm so used to seeing CR-LF that my code broke because I was assuming that's what I would see for line endings.

You need to use GT_USECRLF as the flags member of the GETTEXTEX structure

Actually, it's nice only having one line terminator instead of two.
CR-LF seems to be an ancient holdover from the days of teletype terminals and such, when CR actually returned the carriage and LF fed a new line, just like a typewriter. How quaint.

#14

The Workshop / Re: Challenge: Hexify #s

Last post by sinsi - December 03, 2024, 07:57:23 PM

Also, JJ, something I noticed while coding my comma-delimiting code:
The buffer I got from my RichEdit control (using EM_GETTEXTEX) only had carriage returns (0Dh) with no line feeds (0Ah). Is this the way all (ASCII) text in a RichEdit control is encoded? I'm so used to seeing CR-LF that my code broke because I was assuming that's what I would see for line endings.

You need to use GT_USECRLF as the flags member of the GETTEXTEX structure

#15

The Workshop / Re: Challenge: Hexify #s

Last post by zedd151 - December 03, 2024, 07:56:56 PM

Also, JJ, something I noticed while coding my comma-delimiting code:
The buffer I got from my RichEdit control (using EM_GETTEXTEX) only had carriage returns (0Dh) with no line feeds (0Ah). Is this the way all (ASCII) text in a RichEdit control is encoded? I'm so used to seeing CR-LF that my code broke because I was assuming that's what I would see for line endings.

Yes rich edit likes to save bytes.    No 'trailing' line feed.
When I started working with rich edit code years ago, that threw me off too.

@sinsi, I never knew about that one.  Nice.     (post below this one)

#16

The Workshop / Re: Challenge: Hexify #s

Last post by NoCforMe - December 03, 2024, 07:51:10 PM

Also, JJ, something I noticed while coding my comma-delimiting code:
The buffer I got from my RichEdit control (using EM_GETTEXTEX) only had carriage returns (0Dh) with no line feeds (0Ah). Is this the way all (ASCII) text in a RichEdit control is encoded? I'm so used to seeing CR-LF that my code broke because I was assuming that's what I would see for line endings.

#17

The Workshop / Re: Challenge: Hexify #s

Last post by NoCforMe - December 03, 2024, 07:44:39 PM

Hmm, pretty slick there.
Still digesting this.
One tiny quibble: where you use

Code Select Expand

.if al>="A"
mov byte ptr [edi], "0" ; add leading zero
what if the hex chars use lowercase "a-f" instead, which is permitted? (My code allows either.)

I don't yet understand how all those stosds (like 20206464h work, but I'm sure it's very clever.

So we have a contest entry here.

#18

The Workshop / Re: Challenge: Hexify #s

Last post by jj2007 - December 03, 2024, 07:14:53 PM

Code Select Expand

  Let esi=FileRead$("raw.txt")
  add Len(esi), 1000 ; whatever is needed to compensate
  Let edi=New$(eax) ; leading zeros and trailing "h"
  push edi ; for printing
  .Repeat
lodsb ; 1800: 1A161A D8E7F0 19151A
  .Until al==":" || !al
  mov eax, 20206464h
  stosd
  dec edi
  .While al
.Repeat
lodsb
.Until al>"0" || !al ; D8E7F0
.Break .if !al
.if al>="A"
mov byte ptr [edi], "0" ; add leading zero
inc edi
.endif
.Repeat
stosb
lodsb
.Until al<"0"
.if al==" "
mov eax, "  ,h" ; 202C68
.else
mov eax, 0A0D68h ; h CrLf
stosd
.Break .if dword ptr [esi]<=0A0Dh ; no dd at end of file
dec edi
mov eax, 20206464h
.endif
stosd
dec edi ; write three characters
  .Endw
  pop edi
  PrintLine edi


Code Select Expand

dd 1A161Ah, 19161Ah, 19151Ah, 1C181Dh, 1D191Eh, 1B171Ch, 1E1A1Fh, 1E1A1Fh
dd 1F1B20h, 1C181Dh, 1D191Eh, 1C181Dh, 191619h, 1C191Bh, 1C181Ch, 201C21h
dd 1B171Dh, 19151Bh, 1B171Dh, 1D191Fh, 1F1B21h, 1D191Fh, 1A161Ch, 1D181Eh
dd 1D191Fh, 1C1B21h, 1C1C22h, 1B181Eh, 1D171Dh, 1B171Ch, 1B171Ch, 1B171Ch
dd 1B171Ch, 1C181Dh, 1D1B20h, 303138h, 81838Bh, 0BABFC4h, 0D7DFE0h, 0E1ECEBh
dd 0D8E7F0h, 0DFEDF5h, 0E6F1F7h, 0ECF6F9h, 0E4ECEDh, 0E0E7E4h, 0EEF4EFh, 0ECF2EEh
dd 0D4D9D7h, 0A0A5A4h, 0BEC3C2h, 848A8Ah, 414747h, 414545h, 2E3030h, 282829h
dd 232024h, 252127h, 28242Ah, 211D23h, 1B171Ch, 1C181Dh, 1A1719h, 181517h
dd 171416h, 171416h, 181517h, 161315h, 171416h, 171416h, 161315h, 161315h
dd 161315h, 171214h, 181315h, 171214h, 181315h, 191416h, 181416h, 161315h
dd 161315h, 161315h, 171416h, 171416h, 161415h, 161315h, 171417h, 181418h
dd 171318h, 181418h, 161315h, 181518h, 19151Ah, 1B171Ch, 221D23h, 2A232Ch
dd 332C36h, 423B45h, 4F4955h, 5F5A66h

#19

The Workshop / Re: Challenge: Hexify #s

Last post by zedd151 - December 03, 2024, 09:54:58 AM

Haven't really delved into it yet. I might pass that off to daydreamer..    How about it, Magnus? 

I'm  a little busy solving a problem of my own making, at the moment.   

[*]

#20

The Workshop / Re: Challenge: Hexify #s

Last post by NoCforMe - December 03, 2024, 08:40:20 AM

I'll work on two versions:
One converting the raw hex data to formatted strings,  the other working on formatting the existing ascii hex data.
Both *should* be trivial...

I got my comma-delimiting code working.
So how's your hexification code coming?
Looking forward to, what should we call it? the code showdown? code slam?*

* Like a poetry slam. Friendly competition.