* contrib/hbssl/evpmd.c
* contrib/hbssl/hbssl.h
* moved hb_EVP_MD_ptr_to_id() function from static to public area
* contrib/hbssl/hbssl.hbx
* contrib/hbssl/hbssl.hbm
+ contrib/hbssl/d2i.c
* added new functions to extract asynchronous keys and certificates
from DER data:
D2I_PUBKEY( <cDER> ) -> <pEVPKey>
D2I_RSAPUBLICKEY( <cDER> ) -> <pRSAKey>
D2I_X509( <cDER> ) -> <pX509Cert>
* contrib/hbssl/hbssl.hbx
* contrib/hbssl/evppkey.c
+ added new functions to get/set RSA asymmetric keys parameters
encapsulated in EVP_PKEY structures:
EVP_PKEY_CTX_get_RSA_padding()
EVP_PKEY_CTX_set_RSA_padding()
EVP_PKEY_CTX_get_RSA_OAEP_md()
EVP_PKEY_CTX_set_RSA_OAEP_md()
EVP_PKEY_CTX_get_RSA_MGF1_md()
EVP_PKEY_CTX_set_RSA_MGF1_md()
* src/common/hbdate.c
* accept up to 9 fractional digits (nanoseconds) in timestamp strings
though only first three ones (milliseconds) are significant.
Recently some tools begin to generate such timestamp values and
Harbour had problems with decoding them correctly.
* src/compiler/hbmain.c
+ allow to pass file name for source code compiled by hb_compileFromBuf()
It works like in all other versions of hb_compile*() functions - it's
enough to pass it as argument without option prefix (option prefix
is "-" on all platforms and also "/" on DOS, OS2, MS-Win).
Please remember that first parameter after control ones is used as
compiler name in generated output messages regardless of its option
prefix.
* src/rtl/cdpapi.c
! fixed hb_cdpUTF8StringPeek() to work with 0 based indexes and
Unicode characters > 0xFFFF
* src/rtl/hbmd5.c
! removed redundant code (copy and past typo)
* include/hbdefs.h
! fix undefined behaviour on signed int overflow in
HB_GET_LE_INT24(), HB_GET_BE_INT24() macros
reported by runtime sanitizer (LLVM -fsanitize-trap=undefined)
panic: left shift of 255 by 24 places cannot be represented
in type 'HB_I32' (aka 'int')
* config/win/zig.mk
! in some Zig tests, building for Windows from UNIX shell (MSYS2
or cross compiling) resource compiler "zig rc" preferred options
passed with "-" instead of "/"
; import hbcrypto.h header that allows reusing core sha functions
by contribs, coming from Viktor's fork:
2015-07-13 19:39 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
2015-07-13 23:12 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
+ include/hbcrypto.h
+ move sha2 and hmac/sha2 related headers to Harbour
header directory so they can be used by other components.
+ export sha2 and hmac/sha2 low-level functions from Harbour dynlib
* src/rtl/sha1.c
* src/rtl/sha1.h
* src/rtl/sha1hmac.c
* src/rtl/sha1hmac.h
* src/rtl/sha2.c
* src/rtl/sha2hmac.c
* src/rtl/hbsha1.c
* src/rtl/hbsha1hm.c
* src/rtl/hbsha2.c
* src/rtl/hbsha2hm.c
+ use Harbour index type in low-level SHA code
% drop high-level hack compensating for fixed sized
low-level indexes in 64-bit builds
* utils/hbmk2/hbmk2.prg
* make the MSVC version detection based on paths a little less
trustful. With rolling releases of these MS tools, it's more
likely that "random" numbers will appear in dir names.
* contrib/hbssl/hbssl.hbc
! actually target VS 2017 for libcrypto, libssl
* utils/hbmk2/hbmk2.prg
! slight rework of MSVC version detection, so it actually operates
with empty cPath_CompC variable
* also try to discover version number of future MSVC releases
* with Zig building GUI applications on Windows, hbmk2 will
now pass -Wl,/subsystem:windows to the linker
* .github/workflows/windows-ci.yml
* encourage to test OpenSSL
* contrib/hbssl/hbssl.hbc
* treat Microsoft Visual Studio 2017 or newer can use
the latest OpenSSL lib. That's very loose approximation,
but hopefully better than before. If you are using such
compiler please update your OpenSSL library.
% deduplicated the rules, leftovers from old static "_s" suffixing
* contrib/hbssl/hbssl.h
* contrib/hbssl/hbssl.hbm
* contrib/hbssl/ssl.c
! HB_OPENSSL_HAS_APPLINK was never checked,
defining HB_OPENSSL_NO_APPLINK didn't do anything
* make current OpenSSL 3.6.0 build under fresh MSYS2
shell. MSYS2 does not distribute applink.c, claiming
MingGW C runtime is safe for operation without it.
Have to define HB_OPENSSL_NO_APPLINK and additional
workaround for lacking __int64 type when including
ssl.h. If you need similar workround outside of
MSYS2 shell, setenv: HB_USER_CFLAGS=-DHB_OPENSSL_MSYS
packages needed: openssl-devel (for headers)
mingw-w64-x86_64-openssl (for libs)
mingw-w64-aarch64-openssl
* contrib/hbssl/hbssl.hbc
* using Clang or Zig compiler on Windows, build will
now reference libssl and libcrypto instead of old
ssleay32/libeay32 pair when linking.
* config/win/zig.mk
% unnecessary check
+ config/bsd/zig-noauto.mk
+ config/bsd/zig.mk
+ config/common/zig-noauto.mk
+ config/common/zig.mk
+ config/darwin/zig-noauto.mk
+ config/darwin/zig.mk
+ config/linux/zig-noauto.mk
+ config/linux/zig.mk
+ config/win/zig-noauto.mk
+ config/win/zig.mk
* config/global.mk
* utils/hbmk2/hbmk2.prg
! typo fixed in Alpha target (this path was really untested)
+ added support for using Zig as LLVM C compiler frontend. Recent
idea comes from Marcos Gambeta Harbour++ fork, though I haven't
borrowed any code. Here the functionalty is complete, whole
Harbour source tree can be compiled, together with shared libs.
Zig has unique ability of managing cross-compiled builds, mostly
without downloading anything else. For example you should be able
to easily make a Linux+musl libc build of your Harbour application
that will run on any distribution with Linux kernel >= 2.6.39 (untested).
Zig is not auto-detected by the Harbour build process, HB_COMPILER=zig
has to be defined. The only exception is that, hbmk2 on Windows can
locate "zig.exe" while building final Harbour applications. Usually
there are no conflicting tools on PATH on this platform.
After downloading zig from https://ziglang.org/download/
specific to your OS, assuming the tool being unpacked to
/home/user/zig or C:\zig, usage is as follows:
Linux/BSD native build:
PATH=$PATH:/home/user/zig
HB_COMPILER=zig make -j8
Unix to Windows x64 cross:
PATH=$PATH:/home/user/zig
export HB_ZIG_TARGET=x86_64-windows
# (or) export HB_ZIG_TARGET=x86_64-windows-gnu
export HB_CPU=x86_64
# have to build a Harbour for your host first, for a native hbmk2
export HB_HOST_BIN=/home/user/harbour/bin/linux/zig
export HB_PLATFORM=win
export HB_BUILD_NAME=64cross
export HB_COMPILER=zig
make -j16
Windows native build:
PATH=C:\zig;%PATH%
set HB_COMPILER=zig
win-make -j8
Windows to Windows-on-ARM cross:
set HB_ZIG_TARGET=aarch64-windows
set HB_CPU=arm64
set HB_HOST_BIN=C:\harbour\bin\win\zig
set HB_COMPILER=zig
win-make -j8
Windows to Linux ARM64:
set HB_USER_CFLAGS=-fPIC
set HB_ZIG_TARGET=aarch64-linux
set HB_PLATFORM=linux
set HB_CPU=arm64
set HB_HOST_BIN=C:\harbour\bin\win\zig
set HB_COMPILER=zig
win-make -j8
Instead of setting HB_ZIG_TARGET, the less convenient way is:
HB_USER_CFLAGS=-target aarch64-linux
HB_USER_LDFLAGS=-target aarch64-linux
HB_USER_DFLAGS=-target aarch64-linux
Some target platforms need PIC mode even for static builds,
in such case add:
HB_USER_CFLAGS=-fPIC
; TOFIX: shared lib symlinks are not created when cross-building from
Windows to Linux, could copy or adapt modern Windows counterpart
olectl.h is missing when cross-building hbwin contrib from
Linux to Windows (likely needs headers from Windows SDK)
basically a non issue, but HB_CPU and HB_PLATFORM are not guessed
from HB_ZIG_TARGET - conversion table seems to be doable, if
someone is interested in making a patch.
* config/global.mk
* follow up to previous, define __ARCH64BIT__ for .prg files
if applicable during first stage done by GNU Make
* consider Alpha a 64-bit CPU too when it's a cross-build target
(untested)
* utils/hbmk2/hbmk2.prg
* updated stored list of Visual Studio (2013-2022) versions to C comp
revisions, which could be used in .hbp files HB_COMP_VER macro
; https://learn.microsoft.com/en-us/cpp/overview/compiler-versions
more detailed versioning available if someone is interested in that
please submit a patch that would translate C compiler path to
version according to the linked rules - MSVC now has rolling
releases
* utils/hbmk2/hbmk2.prg
* updated approach to define __ARCH64BIT__ at .prg level when
cross-compiling for such architecture.
Thanks to Alexey Zapolskiy for noticing.
+ local hb_RightEq() deployed as macro
* include/hbdefs.h
+ added new types HB_WCHAR16 and HB_WCHAR32, existing type HB_WCHAR
is mapped to HB_WCHAR16 (just like before)
* include/hbapicdp.h
* src/harbour.def
* src/rtl/cdpapi.c
+ added new C functions for encoding and decoding UTF-8 string using
which HB_WCHAR32:
int hb_cdpU32CharToUTF8( char * szUTF8, HB_WCHAR32 wc );
HB_BOOL hb_cdpUTF8GetU32( const char * pSrc, HB_SIZE nLen,
HB_SIZE * pnIndex, HB_WCHAR32 * pWC );
HB_BOOL hb_cdpUTF8GetUCS( const char * pSrc, HB_SIZE nLen,
HB_SIZE * pnIndex, HB_WCHAR32 * pWC );
HB_BOOL hb_cdpUTF8GetU16( const char * pSrc, HB_SIZE nLen,
HB_SIZE * pnIndex, HB_WCHAR16 * pWC );
HB_BOOL hb_cdpUTF8Validate( const char * pSrc, HB_SIZE nLen );
They support full UCS and are much more restrictive against errors and
wrong UTF-8 encoding, i.e. now overlong encoding is forbidden.
The wrong characters are translated to 0xFFFD and later if such
character does not exist in final CP to '?' ASCII character.
* declaration of the following UTF-8 C functions have been changed to
operate on HB_WCHAR32 instead of HB_WCHAR:
int hb_cdpUTF8CharSize( HB_WCHAR32 wc );
HB_WCHAR32 hb_cdpUTF8StringPeek( const char * pSrc, HB_SIZE nLen,
HB_SIZE nPos );
* the following C functions have been changed to internally operate on
HB_WCHAR32 instead of HB_WCHAR:
hb_cdpUTF8StringLength()
hb_cdpUTF8StringAt()
hb_cdpUTF8StringSubstr()
* the following C functions have been changed to use new hb_cdpUTF8GetU*()
instead of step by step decoding with hb_cdpUTF8ToU16NextChar()
hb_cdpStrToUTF8Disp()
hb_cdpUTF8AsStrLen()
hb_cdpUTF8ToStr()
hb_cdpStrToU16()
hb_cdpUtf8Char()
* use HB_CDP_ERROR_* macros to mark wrong encoding
* src/rtl/cdpapihb.c
* the following UTF-8 C functions have been changed to operate on
HB_WCHAR32 instead of HB_WCHAR:
hb_utf8Chr()
hb_utf8Asc()
hb_utf8Poke()
hb_utf8Peek()
Other UTF-8 PRG functions have been adopted to HB_WCHAR32 by changes
in corresponding C functions.
* src/codepage/cp_utf8.c
* use new function hb_cdpUTF8GetU16() to decode UTF-8 strings in UTF8EX CP
* src/rtl/arc4.c
+ added new macro HB_NO_SYSCTL which allow to disable sysctl() in Linux
builds for GLIBC < 2.30
* src/rtl/cdpapi.c
+ added fallback translation table for different variants of Latin
character, now when translation is made between different encoding
and the variant of Latin character does not exist in destination
code page then it's translated to their base Latin form, i.e.:
hb_utf8ToStr( "ĄĆĘŁŃÓŚŹŻąćęłńóśźż", "EN" ) -> "ACELNOSZZacelnószz"
* tests/uc16_gen.prg
; updated comment
+ contrib/hbbmp/core.c
+ contrib/hbbmp/hbbmp.ch
+ contrib/hbbmp/hbbmp.h
+ contrib/hbbmp/hbbmp.hbc
+ contrib/hbbmp/hbbmp.hbp
+ contrib/hbbmp/hbbmp.hbx
+ contrib/hbbmp/readme.txt
+ contrib/hbbmp/tests/hbbmptst.prg
+ contrib/hbbmp/tests/hbmk.hbm
+ added new BMP image library for Harbour
; HBBMP is small library for Harbour dedicated to create and modify
BMP images. It has not any 3rd party libs dependencies.
See readme.txt for more information
+ contrib/hbzebra/tests/bmp.prg
+ added example code which uses HBBMP as backend for HBZEBRA and
creates BMP images with generated barcodes.
* contrib/hbzebra/coredraw.c
* contrib/hbzebra/hbzebra.hbx
+ added new PRG function:
hb_zebra_getsize( <hZebra>, @<nWidth>, @<nHeight> ) -> <nError>
it calculates size in points of the created barcode and returns 0 on
success or error code
+ contrib/hbzebra/tests/gtgfx.prg
+ borrowed from Viktor's fork, thanks
2014-09-18 22:32 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
+ added on-screen barcode example, created by elch
(with some minor cleanups)
https://groups.google.com/d/msg/harbour-users/_Wht51JZGgE/ZXyvaJNH9ggJfeb4fc0e20
* contrib/sddoci/core.c
* map ostrlen() to strlen() or wcslen() in OCI_CHARSET_UNICODE builds
; TOFIX: this library uses wchar_t for unicode strings, it means that
in *nixes where wchar_t is 32-bit integer mapping to Harbour
HB_WCHAR is wrong and has to be fixed
* include/hbapifs.h
* src/harbour.def
* src/rtl/filebuf.c
+ added new C function:
HB_BOOL hb_fileSave( const char * pszFileName,
const void * buffer, HB_SIZE nSize );
* include/harbour.hbx
* src/harbour.def
* src/rtl/vfile.c
+ added new PRG function:
hb_vfSave( <cFileName>, <cFileBody> ) --> <lOK>
* src/rtl/vfile.c
* set FError() code in hb_vfLoad()
* contrib/gtqtc/gtqtc.h
* contrib/gtqtc/gtqtc1.cpp
+ added support for disabling title and frames of console window by
hb_gtInfo( HB_GTI_WINTITLE, <lNoFrame> )
* src/rtl/transfrm.c
! fixed bug in "@S<n>" transformation when multibyte CDP is used
* contrib/hbhpdf/core.c
+ HPDF_GetPageByIndex( hDoc, nIndex ) --> hPage / NIL
suggested by Luigi Ferraris
* contrib/hbhpdf/tests/harupdf.prg
+ test the above (disabled by default)
* README.md
* updated CI badge(s) to GitHub Actions - they also cover
the strict compilation mode, definitions are currently
located in the same file as normal
! cleaned up links, mostly in tools section, some were
broken, for others switched to https where applicable
* mention HB_CCPREFIX= support for clang
* contrib/hbdoc/hbdoc.prg
* contrib/hbformat/utils/hbformat.prg
* contrib/hbnetio/utils/hbnetio/hbnetio.prg
* package/harbour.mft
* package/harbour.rc
* src/compiler/hbusage.c
* utils/hbi18n/hbi18n.prg
* utils/hbtest/hbtest.prg
* bumped copyright year to 2025
* contrib/hbpost.hbm
! fix missing contrib/*/tests/files when using "make install"
and HB_INSTALL_PREFIX.
Thanks Jose Quintas for reporting (issue #310)
* config/win/clang.mk
+ add resource compiler detection chain to first stage,
now harbour.exe binary should also have manifest resource
compiled in when clang is used. Previously second stage rc
calling was implemented only in hbmk2.
* utils/hbmk2/hbmk2.prg
! fixed disappearing llvm-ar with fallback to ar, spotted
in windows-ci/MSYS2
+ config/wasm/global.mk
+ config/wasm/libs.mk
+ config/wasm/emcc.mk
* utils/hbmk2/hbmk2.prg
* contrib/hbrun/hbrun.hbp
+ add basic support for build Harbour into JS/WebAssembly using
emscripten, using these settings:
HB_PLATFORM=wasm HB_COMPILER=emcc HB_BUILD_3RDEXT=no
* {abstr} is now a hbmk2 keyword to possibly group all
toolsets similar in flavour: WASI/clang, JS/emscripten
These most likely will be targeting plaforms which are not
full operating-systems, they are also commonly qualified as
sandbox solutions.
* introduced __PLATFORM__WASM and __PLATFORM__ABSTRACT .prg defines
* utils/hbmk2/hbmk2.prg
+ allow to specify hb_ProgName() value at build-time for platforms
where the function cannot return a meaningful value (f.e.
JS/WebAssembly)
; TODO: Add support for passing hb_ProgName() value command-line
parameter, f.e. `--hb:self=hbrun`
* config/global.mk
* include/hbsetup.h
* consider abstract/emscripten targets similar to linux-like
* src/rtl/arc4.c
! fix to build under emscripten (which is assumed to be a
linux-like environment)
; though platform/compiler names are not currently compatible
with origin, this WebAssembly platform support was guided by
Harbour 3.4:
2017-06-09 01:10 UTC Viktor Szakats (vszakats users.noreply.github.com)
as usual Viktor was here before, many thanks!
; example project, how to make a multi-platform GUI application which
also targets WebAssembly, can be found here:
https://github.com/alcz/harbour-cimgui-sokol-starterkit/
* src/rtl/cdpapihb.c
! fixed hb_transalte() to not clear passed string
when neither CPIN nor CPOUT is set
* src/rtl/hbgtcore.c
! fixed hb_gtAttach() to properly work with empty GT pointer
* contrib/hbcurl/hbcurl.hbp
+ added Windows architecture specific libcurl names:
libcurl-x64.dll, libcurl-arm64.dll as suggested
by @carles9000 in #382
* include/hbdefs.h
* contrib/sddsqlt3/core.c
- removed HB_WATCOM_64BUG macro - new versions of OW 2.0 supports 64bit
integers in preprocessor directives - Many thanks to Aleksander who
reported the problem on OpenWatcom V2 forum
+ added test for 64bit support in C preprocessor suggested by Aleksander
* .github/workflows/windows-ci.yml
* minor simplification
