Author Topic: MasmBasic  (Read 16725 times)

jj2007

  • Guest
MasmBasic
« on: December 23, 2015, 06:41:56 PM »
Hello everybody,

For those who don't yet know me from bp.org: I am Jochen, and my hobby is a particular dialect of BASIC:

MasmBasic "compiles" with the standard Microsoft macro assembler aka MASM (and some clones like JWasm and AsmC).

The latest version is always available here at the Masm32 forum. You can find a badly organised overview of the commands here.

MasmBasic is extremely fast and strong on strings (including Unicode) but somewhat weak on arithmetics. Since it is an assembler library, you can do absolutely everything with it, provided your OS is Windows and an Intel or AMD CPU are working under the hood.

Latest features can always be found at the end of the Masm32 thread, currently here.

Here is a screenshot of an application showing three types of edit controls (Scintilla, ordinary Windows edit control, RichEdit) in a resizable window. The source code (here) is a whopping 18 lines long:

P.S.: My sincere thanks to the Retrogamecoding Forum for hosting the "leftovers" of bp.org









« Last Edit: November 07, 2016, 05:52:39 PM by jj2007 »

Richly

  • Guest
Re: MasmBasic
« Reply #1 on: December 23, 2015, 11:05:52 PM »
Hi JJ

Glad you found your way here too.

I didn't have your contact details to let you know about this place after BP.org expired but all's well that ends well  :)

jj2007

  • Guest
Sorting one Million strings per second
« Reply #2 on: December 31, 2015, 08:40:28 AM »
MasmBasic update of 31.12.15 features ultra-fast Advanced string sorting, plus a new function for the GUI fans:

include \masm32\MasmBasic\Res\MbGui.asm
Event Paint
  GuiImage "\Masm32\examples\exampl04\car\car.jpg", fit      ; fit=use full window
GuiEnd


All commands here, step-by-step installation instructions here.

Ed Davis

  • Guest
Re: Sorting one Million strings per second
« Reply #3 on: December 31, 2015, 01:30:46 PM »
MasmBasic update of 31.12.15 features ultra-fast Advanced string sorting,

How hard would it be for you to produce a version that is called as so:

sort input-file output-file

Reads input file, sorts it, and writes it back out to output-file.

Sorting should be case insensitive and stable.

I'd like to benchmark it against a few of my sorts, just to see how slow/fast mine are.

Thanks in any case!


jj2007

  • Guest
Re: Sorting one Million strings per second
« Reply #4 on: December 31, 2015, 05:52:44 PM »
Reads input file, sorts it, and writes it back out to output-file.

Sorting should be case insensitive and stable.

Hi Ed,

Despite its name, QSort is a stable merge sort. Here it is:

include \masm32\MasmBasic\MasmBasic.inc      ; download
  Init
  NanoTimer()
  Recall CL$(), L$()    ; CL$() = use commandline
  .if eax>1
      QSortMode cis
      QSort L$()
  .endif
  Store "Sorted.tmp", L$()
  Inkey Str$("%i lines written to Sorted.tmp", L$(?)), Str$(", %i ms incl. reading & writing", NanoTimer(ms))
EndOfCode


26902 lines written to Sorted.tmp, 12 ms incl. reading & writing

Note that this includes disk operations, so comparability may be low. Use a really fat file, e.g. bible.txt, and repeat the action two or three times to make sure the file content is in the disk cache.

QSortMode cis means case-insensitive
QSortMode cis, sls, MyIndexArray() would mean case-insensitive, skip leading spaces, use MyIndexArray() to keep track of original line index.

Let me know how it works out. And don't forget to celebrate the New Year ;-)

P.S.: New thread A simple chessboard, see second attachment.
« Last Edit: December 31, 2015, 06:00:34 PM by jj2007 »

jj2007

  • Guest
Gdi+
« Reply #5 on: February 08, 2016, 09:52:01 AM »
Beta available here. I hope the interface is intuitive and simple enough to qualify as "BASIC" ;-)

The new functions are not yet published at the Quick Reference, but during the installation the help file opens. You may search for .MbMake


jj2007

  • Guest
Re: MasmBasic
« Reply #6 on: August 30, 2016, 11:35:35 AM »
MasmBasic was updated, download here.

Latest changes:

- more complete dual 64/32 bit include files (no external libraries required)

- GetHash function:

include \masm32\MasmBasic\MasmBasic.inc
      Init
      Let esi=FileRead$("\Masm32\qEditor.exe")
      .if GetHash(esi, LastFileSize, sha)     ; FileRead$ sets LastFileSize, also for binary files
            PrintLine "The SHA of qEditor.exe is   ", Tb$, Hex$(xmm0), " ", Hex$(ecx)
      .else
            PrintLine "Hashing failed: ", Err$()
      .endif
      void GetHash(esi, LastFileSize)
      mov ecx, edx                              ; fifth word returned in edx
      Print "Fast MD5 of qEditor.exe is ", Tb$, Hex$(xmm0), CrLf$
      GetHashRev=1                              ; use official MD5 byte order
      .if GetHash(FileRead$("\Masm32\qEditor.exe"))   ; MD5, len of string will be calculated
            PrintLine "qEditor, byte order MD5 specs: ", Tb$, Hex$(xmm0)
      .endif
EndOfCode


- returns success (1) or failure (0) in eax
- four dwords are returned in xmm0
- in case of SHA, the fifth dword will be in edx
- results can be displayed as a Hex$(xmm0), plus Hex$(edx) for SHA. The byte order will be reversed, compared to
  online hash calculators. You may use GetHashRev=1 to follow the MD5 specs, but more code will be generated
- with only one para, GetHash calculates the length; this is meaningful only for text files

Output for the snippet:
Code: [Select]
The SHA of qEditor.exe is       F383E693 1F7D6EB5 B34F2B52 A30186C1 64050000
Fast MD5 of qEditor.exe is      A6869EAB 7FF88A6B 4E1F20CC 4F8E7DF7
qEditor, byte order MD5 specs:  F77D8E4F CC201F4E 6B8AF87F AB9E86A6

jj2007

  • Guest
Re: MasmBasic
« Reply #7 on: November 07, 2016, 05:47:58 PM »
Update 7 November got a few new features for displaying (and changing) images.

Simple example:
Code: [Select]
include \masm32\MasmBasic\Res\MbGui.asm
Event Paint
  GuiImage wCL$(), fit ; show what was passed via the commandline, fit to window size
GuiEnd

Works with Unicode file names, too.

Mike Lobanovsky

  • Guest
Re: MasmBasic
« Reply #8 on: November 07, 2016, 10:24:37 PM »
Quote from: JJ on MASM32 forum
GuiImage "Это тест.jpg", fit     ; Unicode is allowed

Jochen,

Methinks you're under a wrong impression of the Russian-speaking world being someplace to the far east of you midway between Earth and Jupiter. :D

Russian per se does not require any Unicode excesses, and the 33 glyphs of Russian Cyrillic alphabet occupy the exact same placeholders in the Windows standard CP866, CP1251 and other non-Unicode code pages that your Italiano, Français and Deutsch accents, ligatures, umlauts and other diacritics would use in your respective national code pages for your own language-specific graphics exercises.

Does the Cyrillic alphabet really look to you so alien as e.g. Hiragana would? :D

BTW try to avoid using locale specific alphabets at all costs to store image files under because most of the professional-grade image processing packages would accept ASCII-only path and file names, and Windows ports of Linuxoid image processing software would also most likely fail with pathnames that contain space characters.


Quote from: JJ on MASM32 forum
MemState("WorkingSetSize, abs delta: %__i ", abs delta)

IMHO current GDI object counts would be much more characteristic of, and appropriate for, image processing operations in the app memory because there are lots of potential causes of memory leaks in a user application but GDI object/handle leaks would be directly related to the implementation quality of image processing strategies chosen.

Besides GDI object count would operate on much smaller figures that would make it easier for human perception.

jj2007

  • Guest
Re: MasmBasic
« Reply #9 on: November 08, 2016, 12:44:54 AM »
BTW try to avoid using locale specific alphabets at all costs to store image files

Mike - I will avoid locale specific alphabets at all costs (I always did  :) )

But you pointed me to a little glitch that I fixed in version 8 November, thanks ;)

I issued a bug warning here.

Attached an image viewer and three images. Extract to a temp folder and start the exe. Arrow left/right scrolls through the images, r rotates right, l rotates left, s saves the rotated image (use at your own risk). Note it will not modify the timestamps when saving the image.

Btw how would you handle this in FBSL? Can you post a viewer that does the same?
« Last Edit: November 08, 2016, 01:35:36 AM by jj2007 »

Mike Lobanovsky

  • Guest
Re: MasmBasic
« Reply #10 on: November 08, 2016, 05:52:20 AM »
Mike - I will avoid locale specific alphabets at all costs (I always did  :) )

But you pointed me to a little glitch that I fixed in version 8 November, thanks ;)

I issued a bug warning here.

No Jochen,

I'm afraid you failed to take my advice for serious.

You see, Unicode is not a panacea. It is only as good as the codepages available on your computer. This is why FBSL v3.5 is ANSI and will remain ANSI for the time being. The cost of effort to move its handicrafted intrinsics to Unicode would be too high for me. I'm eager to spend the rest of my days on things in life more attractive than the failing patchwork of hotfixes that would need yet more and more crutches with every passing day. :)

Your message boxes don't display anything in Chinese that's not installed under my current system nor do your locale-specific Chinese and Arabic image files yield themselves for viewing unless of course they have eligible Russian names.

What regards pure Unicode-aware applications, they can be implemented in the current version of FBSL using Windows SDK style programming, even though FBSL's own intrinsics are ANSI only:



You can examine the relevant FBSL code here but you'll be seeing what's in this snapshot only if you have both Hindi and rare Malayalam code pages and fonts installed on your PC.

Mike Lobanovsky

  • Guest
Re: MasmBasic
« Reply #11 on: November 08, 2016, 06:38:31 AM »
Btw how would you handle this in FBSL? Can you post a viewer that does the same?

1. I would handle that using the existing MMX-assisted DynAsm image processing library that's part of FBSL's 2D sprite engine. It allows for all sorts of anti-aliased transformations, including arbitrary angle rotation, of 32-bit translucent ARGB images in real time without resorting to 3rd party libraries like GDI+, which effectively makes it platform independent. It also offers 11 modes of color and alpha blending and lerping and pixel perfect collision detection of 2D sprite object instances built on top of that library.

2. No, I can't post an equivalent viewer because what I'd do would be, er, somewhat more elegant than your quick and dirty example. And it would be just as simple to build. Tell you what, have a look at my anti-aliased sprite resize example instead and don't hesitate to run the attached executable taking special note of the FPS rates on your PC. My readings for an original, minified and magnified cases within a 512x512 px area are shown below.

Here's the relevant code, hardly any longer or more complicated than yours for a Win SDK oriented programmer:

Code: [Select]
#Include <Include\Windows.inc>

' Sprite SDK
#Include "..\..\Library\CSprite2D.inc"
#Include "..\..\Library\Sprite2DLib.inc"

Dim Width As Integer = 512, Height As Integer = 512
Dim PS As String * 64, FPS As Integer
Dim Mx As Integer, My As Integer

' Fixed-size window
SetWindowLong(ME, GWL_STYLE, &H4C80000)(ME, GWL_EXSTYLE, &H40100)
Resize(ME, 0, 0, Width, Height, TRUE)

' Sprite instance creation
Dim SpBack As New CSprite2D(Width, Height)
Dim SpOrig As New CSprite2D
Dim SpTemp As New CSprite2D

' Texture load
SpOrig.LoadFromFile("..\Art\Auto.jpg")

Center(ME): Show(ME)

Begin Events
  Select Case CBMSG
    Case WM_COMMAND
      If CBWPARAM = IDCANCEL Then ' exit on VK_ESCAPE
        PostMessage(ME, WM_CLOSE, 0, 0)
        Return 0
      End If
    Case WM_MOUSEMOVE ' pic size follows mouse
      If LoWord(CBLPARAM) > 0 And HiWord(CBLPARAM) > 0 Then
        Mx = LoWord: My = HiWord
      End If
    Case WM_ERASEBKGND ' suppress flicker
      Return 1
    Case WM_PAINT ' render sprites
      Render(BeginPaint(ME, PS))
      EndPaint(ME, PS)
      InvalidateRect(ME, NULL, TRUE) ' initiate next render
      Return 0
    Case WM_CLOSE ' cleanup
      SpBack.Dispose()
      SpOrig.Dispose()
      SpTemp.Dispose()
  End Select
End Events
' ---------------------------------------------------------------------------------------------

Sub Render(hDC As Integer)
  Static NextTime, cb = ARgb(0, 0, 0, 0)
 
  Incr(FPS)
  If GetTickCount() > NextTime Then ' display info once a second
    NextTime = GetTickCount + 1000
    FbslSetText(ME, "Resize Sprite, FPS = " & FPS)
    FPS = 0
  End If
 
  SpBack.ClearBuffer(cb)
  SpTemp.LoadFromSprite(SpOrig, TrNone, Mx, My)
  SpBack.Draw(SpTemp, 0, 0)
  SpBack.PaintToDevice(hDC) ' copy to window
End Sub

jj2007

  • Guest
Re: MasmBasic
« Reply #12 on: November 08, 2016, 07:45:57 AM »
This is why FBSL v3.5 is ANSI and will remain ANSI for the time being. The cost of effort to move its handicrafted intrinsics to Unicode would be too high for me. I'm eager to spend the rest of my days on things in life more attractive than the failing patchwork of hotfixes that would need yet more and more crutches with every passing day. :)

Mike,
I understand that would be a lot of work for you. Don't do it then.

Quote
Your message boxes don't display anything in Chinese that's not installed under my current system

Re the MessageBox example that you took from here: Of course, if a language pack is not installed on your system, it won't display the text; but it launches the exe, apparently.

I tested your Resize.exe example, it works but the fan starts howling immediately, and one core is at 100%, even if I do nothing. Besides, it doesn't take other pictures when I drag them over the exe, it always shows auto.jpg, so I can't test it with the Chinese images. Is that desired behaviour?

Quote
nor do your locale-specific Chinese and Arabic image files yield themselves for viewing unless of course they have eligible Russian names.

Now that raises an interesting question: When you launch ImageViewAndRotate.exe in a folder with ???.jpg images, do you see the content of these images? I understand that the window titles don't display properly, but GetFiles and the Files$() array should work independently of the installed code pages (because under the hood they use true Unicode); otherwise Windows itself is broken 8)

Mike Lobanovsky

  • Guest
Re: MasmBasic
« Reply #13 on: November 08, 2016, 07:47:44 PM »
Re the MessageBox example that you took from here: Of course, if a language pack is not installed on your system, it won't display the text; but it launches the exe, apparently.

Evening Jochen,

Yes, it does launch the Окносообщения.exe module but only because the Russian codepages are installed under my XP Sp3 Pro Rus and the system PE loader can make out the module file name's characters and tell them from a string of control characters of unknown origin and/or intent. Had the file been called 您可以将中文文本传递到应用程序。.exe, whatever that means, the PE loader would report file corruption with unpredictable consequences to the integrity of the system. (I wouldn't allow it to even attempt lauching your sample in this case though.)

Tell you more, file name corruption was widely popular as an exploit for the creation of unkillable bootable USB stick virii some half a decade ago or so. The virus would create a hidden System Volume Information folder (which is nothing unusual for Vista+ platforms) but with spaces denoted by unpermissible characters on a USB stick that never saw anything better than an XP! The spaces would make the "folder" undeletable and, moreover, unkillable even with the system's standard deep formatting! The system would just mark those USB sectors as bad but wouldn't delete the actual data written in them. So, the virus would then go dormant till the user decided to burn or copy a bootable ISO image onto their CD/DVD drive or USB stick/disk, in which case the virus would create a jump to the "bad" sectors from the stick's or disk's MBR (master boot record). The system being started from such an infected ISO image is yet unaware of any bad sectors in its data storage devices when it's still in the first 512 bytes of its MBR, so it would obediently jump over there to execute whatever the virus had to offer in its "System Volume Information" sectors. :o

Moreover, Ubuntu that's installed on one of my multi-bootable disks with shared folders would use its standard screen capture utility to save its screenshots under unique PNG names but in a YYYY:MM:DD:HH:MM:SS.PNG format with literal colons in it! The other Windows systems installed on the same physical disk wouldn't quite naturally accept those files as valid images but, what's the worst thing of all, they wouldn't allow me to rename, move or even delete them either! Bravo Linux and Linuxoids! You're halfway there to creating yet another virus on my Windows PC! ;)

Quote
I tested your Resize.exe example, it works but the fan starts howling immediately, and one core is at 100%, even if I do nothing. Besides, it doesn't take other pictures when I drag them over the exe, it always shows auto.jpg, so I can't test it with the Chinese images. Is that desired behaviour?

The desired behavior of this sample is to show off the real speed with which the library is able to perform anti-aliased transformations, rather than what damage can be done to the OS file system with compromised image file names and time stamps that meddle with the NTFS security layout.

100% on just one core out of four wouldn't do any harm to your laptop and is only 25% of the total, after all. As you can see from the code, only the following lines are responsible for rendering while all the rest is just Windows standard app launching/benchmarking stuff: (pseudocode!)

Code: [Select]
    Case WM_PAINT ' render sprites
      Render(BeginPaint(ME, PS))
          SpBack.ClearBuffer(cb)
          SpTemp.LoadFromSprite(SpOrig, TrNone, Mx, My)
          SpBack.Draw(SpTemp, 0, 0)
          SpBack.PaintToDevice(hDC) ' copy to window
      EndPaint(ME, PS)
      InvalidateRect(ME, NULL, TRUE) ' !!! THIS IMMEDIATELY INVALIDATES WHAT'S JUST BEEN PAINTED TO INITIATE NEXT RENDER WITHOUT ANY DELAYS TO COOL OFF YOUR CPU/GPU/WHATEVER !!!

That's a standard procedure for GDI benchmarking and that's effectively also how DirectX and OpenGL would operate when your GPU is set to favor speed over quality (no VSYNC-ing et al.)

Now open up your ImageViewAndRotate, drag some (Chinese) photo onto it, maximize the window and keep on pressing your R key for awhile only to see your CPU rise up to 25% and your fans go humming again. So, is your viewer in fact any better than mine? ;)

Quote
Now that raises an interesting question: When you launch ImageViewAndRotate.exe in a folder with ? ? ?.jpg images, do you see the content of these images? I understand that the window titles don't display properly, but GetFiles and the Files$() array should work ...

No, the content of these images is never shown in either your viewer or my authentic ACDSee Photo Editor I used to pay a damned lot of hard cash for. (I thought you'd be able to read its blue window messages since you seem to be so fond of Russian sample stuff... :) ) It says it couldn't find the respective image files and that they probably had been moved or deleted before it could decode them etc., except of course for my avatar that it obediently shows in its preview.
« Last Edit: November 09, 2016, 02:15:28 AM by Mike Lobanovsky »

jj2007

  • Guest
Re: MasmBasic
« Reply #14 on: November 09, 2016, 12:34:00 AM »
Mike is pushing me to explore the limits of Unicode :)

Attached two new examples - extract to a new folder, launch
Code: [Select]
a) LaunchUnicodeExes.exe (should produce what's shown in the screenshot)
b) ImageViewAndRotate.exe
to test them. Grateful for feedback 8)

Sources are included as *.asc files, building requires Masm32 and the latest November 9 MasmBasic.