Basicprogramming(.org) > Community news and announcements

MasmBasic

<< < (2/7) > >>

jj2007:
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:
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: ---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

--- End code ---

jj2007:
Update 7 November got a few new features for displaying (and changing) images.

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

Works with Unicode file names, too.

Mike Lobanovsky:

--- Quote from: JJ on MASM32 forum ---GuiImage "Это тест.jpg", fit     ; Unicode is allowed
--- End quote ---

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)
--- End quote ---

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:

--- Quote from: Mike Lobanovsky on November 07, 2016, 10:24:37 PM ---BTW try to avoid using locale specific alphabets at all costs to store image files
--- End quote ---

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?

Navigation

[0] Message Index

[#] Next page

[*] Previous page