News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

A guide to the RichMasm editor

Started by jj2007, April 28, 2016, 10:09:34 PM

Previous topic - Next topic

FORTRANS

Hi,

   Just for feedback, a screenshot.

HTH,

Steve

jj2007

Hi Steve,

The lines are wrapped. What's your screen resolution? Mine is 1366x768, and even with enlarged fonts they are not long enough to wrap. Or did you mean something else?

Jochen

FORTRANS

Hi Jochen,

Quote from: jj2007 on July 12, 2017, 04:12:43 AM
The lines are wrapped. What's your screen resolution?

   Usually 1024x768.  Sometimes higher, though not very often.

QuoteMine is 1366x768, and even with enlarged fonts they are not long enough to wrap. Or did you mean something else?

   Well, yes the lines wrap, but I just thought you might find it
useful to see your work on another's system.  Maybe the colors
and fonts are different for instance.  You may try to have all your
computers set up similarly.  I used to do that a while back, and
had some odd results when one of my programs was used on
someone else's computer.  (Code page different I think.)

Regards,

Steve N.

jj2007

Quote from: FORTRANS on July 12, 2017, 05:10:38 AMWell, yes the lines wrap, but I just thought you might find it useful to see your work on another's system.  Maybe the colors and fonts are different for instance.

Colours and fonts look similar, but 1024x768 is indeed a bit low for today's standards. Anyway, it's the browser who decides when to wrap lines.

But I understand the problem very well. Often, pages just look garbled, OK buttons are below the visible area, etc - messy sites made by professional web developers who only made one small mistake: to assume that the user also has that great 4k screen that a decent IT professional is entitled to enjoy 8)

HSE

Good practice is:
include \masm32\MasmBasic\MasmBasic.inc         ; download
  if 0  ; copy the line below, then hit F6 to get the db version
        chartab                 dw "10","01","12","21","13","31"
        ; expected output:
        chartab                 db "0","1","1","0","2","1","1","2","3","1","1","3"
  endif
  Init                          ; *** translate Masm dw format to db for use with UAsm ***
  Let esi=Clip$()               ; get string from clipboard (limit is about 160k)
  lea ecx, [2*Len(esi)]         ; the byte format is longer, so we need a bigger buffer
  Let edi=New$(ecx)
  push esi
  push edi
  .Repeat
        lodsb
        If_ al=="w" Then mov al, "b"    ; dw->db
        stosb
        .Break .if !al
        .if al==34
                push [esi]
                lodsb
                movsb           ; first digit
                mov al, 34
                stosb
                mov al, ","
                stosb
                mov al, 34
                stosb
                pop eax
                stosb           ; second digit
                movsb           ; second quote
        .endif
  .Until 0
  pop edi
  pop esi
  Inkey "Before: ", esi, CrLf$, "After:  ", edi, CrLf$, "Copy to clipboard? (y)", CrLf$
  If_ eax=="y" Then SetClip$ edi
EndOfCode
And everybody can to choose colors :biggrin:
Equations in Assembly: SmplMath

jj2007

Quote from: HSE on July 12, 2017, 06:40:19 AM
Good practice is:

So why do almost all IDEs and many programming sites come along with syntax highlighting? Bad practice?

HSE

In the box is more easy to copy!!

LATER: I also have configurated 1024x768
Equations in Assembly: SmplMath

FORTRANS

Hi,

   BTW, if I have a choice of wrapped comments or uncommented
code, I choose having wrapped comments.  Many denizens of
this forum seem to like uncommented code though.  Maybe they
have a phobia of wrapping.  <g>

Cheers,

Steve

jj2007

Quote from: HSE on July 12, 2017, 08:11:17 AM
In the box is more easy to copy!!

That was before the Mozilla "coders" decided to disable the Code: [Select] function :(

Quote from: FORTRANS on July 12, 2017, 10:28:40 PM
I have a choice of wrapped comments or uncommented code, I choose having wrapped comments.

The code box doesn't wrap them, that may look better but to read them you have to click the horizontal scroll bar. Not the best solution either :icon13:

  Recall Utf8$(wCL$()), L$()    ; translate the file supplied through the (Unicode) commandline to a text array (if the file is Unicode, the strings will be in UTF-8 format; if needed, you can get Unicode back with wRec$(L$(n)) - see also ConvertCp$)


  Recall Utf8$(wCL$()), L$() ; translate the file supplied through the (Unicode) commandline to a text array (if the file is Unicode, the strings will be in UTF-8 format; if needed, you can get Unicode back with wRec$(L$(n)) - see also ConvertCp$)

jj2007

I am trying to figure out if it's worthwhile to look for the debugger paths when doing a fresh install of MasmBasic. Currently, the default paths are hardcoded (see: integrated debugging) to

\Masm32\x64Dbg\release\x64\x64dbg.exe for 64-bit debugging
\Masm32\OllyDbg\ollydbg.exe for 32-bit code.

Therefore the question: Where are your debuggers located?

Biterider

Hi
only as a hint, Visual Studio stores the debugger location here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]


Biterider

LiaoMi

Quote from: jj2007 on October 10, 2017, 02:47:44 AM
I am trying to figure out if it's worthwhile to look for the debugger paths when doing a fresh install of MasmBasic. Currently, the default paths are hardcoded (see: integrated debugging) to

\Masm32\x64Dbg\release\x64\x64dbg.exe for 64-bit debugging
\Masm32\OllyDbg\ollydbg.exe for 32-bit code.

Therefore the question: Where are your debuggers located?

Unchangeable folder paths in this case better  :P

jj2007

include \masm32\MasmBasic\MasmBasic.inc
  Init
  PrintLine GetRegVal("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug", "Debugger")
  SetReg64
  Inkey GetRegVal("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug", "Debugger")
EndOfCode


yields
"C:\Masm32\OllyDbg\ollydbg.exe" -AEDEBUG %ld %ld
"C:\Masm32\x64Dbg\release\x64\x64dbg.exe" -a %ld -e %ld

I attach the project. These are the just-in-time debuggers, should be fine :t

Btw a pretty old key: The AeDebug subkey stores user preferences for Dr. Watson and other debugging tools that run on Windows 2000

No such key on Win10, but Olly shows up at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RADAR\HeapLeakDetection\DiagnosedApplications\ollydbg.exe  :bgrin:

Quote from: LiaoMi on October 10, 2017, 05:39:20 AMUnchangeable folder paths in this case better  :P

Why that?

LiaoMi

Quote from: jj2007 on October 10, 2017, 06:03:27 AM

Quote from: LiaoMi on October 10, 2017, 05:39:20 AMUnchangeable folder paths in this case better  :P

Why that?

Hi,

the debugger often receives updates, sometimes there are errors that you need to debug. I have three versions, clean current release, stable version for work, and the current version with plug-ins, this package is always updated by adding plugins or changing the settings. Therefore, the exact binding for me is better  :biggrin:

jj2007

Quote from: LiaoMi on October 10, 2017, 10:45:30 PMI have three versions, clean current release, stable version for work, and the current version with plug-ins, this package is always updated by adding plugins or changing the settings. Therefore, the exact binding for me is better  :biggrin:

OK, so the best solution will be to
- test if a debugger is already set in RichMasm's prefs
- if not, check for the registry key
- if there is none, see if there is *dbg*.exe inside the \Masm32 tree.

I guess that will add a few hundred bytes to RichMasm's 72kB :(