* 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 "/"
* 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
* 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/
* config/global.mk
* config/win/clang-noauto.mk
* config/win/clang.mk
* supplemented config for Windows clang cross compilers
distributed in multilib fashion, like Martin Storsjo's:
https://github.com/mstorsjo/llvm-mingw
+ HB_CCPREFIX= support for clang on Windows, you can build
ARM64 Harbour from AMD64 hosts using mentioned toolchain:
set PATH=C:\llvm-mingw\bin;%PATH%
set HB_COMPILER=clang
win-make (build for your host first)
set HB_CCPREFIX=aarch64-w64-mingw32-
set HB_HOST_BIN=<HarbourPath>\bin\win\clang\ (if not autodetected)
win-make
; cross compiling from Unix hosts is not yet tested, but
looks very close to be possible
! fixed typo's
* utils/hbmk2/hbmk2.prg
* changed llvm-ar call to also respect HB_CCPREFIX
* .github/workflows/windows-ci.yml
* update windows MSYS2 integration runner set of
requested packages. PGSQL, Firebird and MariaDB libs
are no longer available in the 32-bit environment
+ add clang x86_64 compiler for testing under this CI
* include/harbour.hbx
* include/hbapi.h
* src/common/hbver.c
* src/harbour.def
* src/rtl/version.c
! fixed Windows 11 detection, by vendor likings it has
NT Kernel Version stamped with 10.0, so now Build Number
is more significant as a recognition factor.
+ new C helper functions hb_winisbuild(), hb_iswin11()
+ added PRG function hb_osIsWin11()
* also try to detect new Windows Server versions
* config/win/clang.mk
* utils/hbmk2/hbmk2.prg
* ChangeLog.txt
! recursion happening in the Makefiles rendered recently
introduced compatibility option unreliable. Changed to
use separate variable: HB_USER_FIXES=--mingw-script
You don't need it, the problem shouldn't exist, but
anyway...
+ config/win/clang-noauto.mk
+ additional clang flavour checking when the compiler is specified
via set HB_COMPILER=clang (not auto-detected)
This is important for distributions of clang that bundle both
gcc and clang in the same directory. Harbour 3.2 by default
prioritize gcc over clang.
For example you should be now able to build from winlibs.com by
Brecht Sanders with environment setup such as:
PATH=C:\winlibs\mingw64\bin;%PATH%
HB_COMPILER=clang
win-make
* config/global.mk
! added workaround for common GNU Make issue with
$(dir path with spaces/file) macro, commonly striking on Windows
systems under "Program Files", but also possible in other setups.
Workaround is to call $(call dir_with_spaces,$(HB_COMP_PATH)).
I have only used this workaround in clang detection, but keep
this in mind while revisiting detection of another compiler.
* config/win/clang.mk
* utils/hbmk2/hbmk2.prg
* another rework of Clang on Windows detection (ARM64, x86_64, x86),
solved problems with different availability of resource compiler,
They are now probed in order: windres, llvm-windres, llvm-rc.
* added option to use MinGW INPUT(file.o) link scripts for old tools
To apply workaround with clang, set HB_USER_DFLAGS=--mingw-script
It is not supported in at least some of current clang toolchains,
but it's still needed to succesfully build on old ones (those
using GNU ld on Windows).
* config/global.mk
! detect ARM64 CPU on Windows also under non-native shell (MSYS2 sh)
* on unix also recognize aarch64 from uname
* include/hbsetup.h
* __MINGW64__ define is not x86_64 specific anymore
* config/win/clang.mk
* utils/hbmk2/hbmk2.prg
* reworked Clang on Windows detection (ARM64, x86_64, x86),
now it recognizes those flavours in PATH as distributed
by MSYS2 project and also Visual Studio 2022 Build tools.
Starting Harbour build process should be now possible
both from MSYS2 shell (with the special note to use "make"
command instead of "win-make" from sh) and regular batch
script/cmd shell.
Building on Clang distributed by MS x86_64:
PATH=<InstallPath>\BuildTools\VC\Tools\Llvm\x64\bin;%PATH%
win-make
Clang/MS ARM64:
PATH=<InstallPath>\BuildTools\VC\Tools\Llvm\ARM64\bin;%PATH%
win-make
Building on Clang x86_64 distributed by MSYS2 from cmd:
PATH=C:\msys64\clang64\bin;%PATH%
win-make
Clang/MSYS ARM64 called from cmd:
PATH=C:\msys64\clangarm64\bin;%PATH%
win-make
* src/common/hbver.c
* patched clang version string builder to skip duplicate version
number in some builds
* append processor architecture to clang compiler string
on non-Intel systems
+ config/win/msvcarm.mk
+ config/win/msvcarm64.mk
* config/global.mk
* include/hbsetup.h
* utils/hbmk2/hbmk2.prg
+ introduced support for Windows (10,11) ARM 64-bit platform
native compilers using Visual Studio 2022 Build Tools
before calling win-make, setup environment with:
<InstallPath>\BuildTools\VC\Auxiliary\Build\vcvarsarm64.bat
toolchain should be autodetected as following:
! HB_HOST_PLAT: win (arm64) HB_SHELL: nt
! HB_PLATFORM: win (arm64) (auto-detected)
! HB_COMPILER: msvcarm64 (auto-detected: C:/Program[...]/ARM64/)
to build final application with hbmk2 adding a valid Windows
Platform SDK / CRT paths to INCLUDE= and/or LIB= variable
is needed
; cross compilation from AMD64 hosts is possible:
vcvars64.bat
win-make (build Harbour for your host first)
set HB_HOST_BIN=<HarbourPath>\bin\win\msvc64
vcvarsamd64_arm64.bat
win-make
+ also added support for Windows for ARM 32-bit
before calling win-make, setup environment using:
<InstallPath>\BuildTools\VC\Auxiliary\Build\vcvarsarm.bat
or when cross compiling from ARM64 host:
<InstallPath>\BuildTools\VC\Auxiliary\Build\vcvarsarm64_arm.bat
; please test Windows CE builds if you're using compiler newer
than VC2003 for ARM for possible regressions
* contrib/hbmlzo/3rd/minilzo/lzodefs.h
! recognize ARM64 architecture on Windows to fix build error
; consider updating to upstream minilzo 2.10, issue is fixed there
* src/common/hbver.c
* changed to add processor architecture for MSVC compiler string
on non-Intel systems, as exposed by hb_compiler(), harbour /build,
finalapp.exe //build
* tests/speedtst.prg
* workaround that processor architecture can now appear
in hb_compiler(), so it's not printed by speed test twice
2023-11-11 19:42 UTC+0100 Phil Krylov (phil a t krylov.eu)
* config/win/mingw.mk
* utils/hbmk2/hbmk2.prg
! Use -D__USE_MINGW_ANSI_STDIO=0 to opt out of C99 printf emulation on
MinGW-W64 10.0+.
* config/linux/clang.mk
! fixed rule for dynamic library
* src/3rd/png/Makefile
+ added -DPNG_ARM_NEON_OPT=0 to build flags
* contrib/3rd/sqlite3/sqlite3.c
* contrib/3rd/sqlite3/sqlite3.diff
! pacified warning
* contrib/gtwvg/gtwvgd.c
* contrib/gtwvg/wvgwing.c
! fixed missing break/return in case statements - please verify it.
* contrib/hbct/dattime3.c
* added #define _DEFAULT_SOURCE necessay in new Linux distors
* contrib/hblzf/3rd/liblzf/liblzf.diff
* contrib/hblzf/3rd/liblzf/lzfP.h
* do not use nested #define in #if statements - some C compilers do not
support it
* contrib/hbssl/bio.c
! tuned #if condition
* contrib/hbmisc/hbeditc.c
* simpliefied for condition and pacified warning
* contrib/hbodbc/hbodbc.hbp
* contrib/sddodbc/sddodbc.hbp
+ added check for iodbc library
* utils/hbmk2/hbmk2.prg
+ added support for clang in android builds
* include/hbdefs.h
+ added check for __BYTE_ORDER__ macro used in some new lib C
implementations
* include/hbapi.h
* include/hbdefs.h
* include/hbstack.h
* include/hbvmpub.h
* src/vm/classes.c
* src/vm/dynsym.c
* src/vm/estack.c
* src/vm/memvars.c
+ extended the size of dynamic symbol table from 65535 to 4294967295.
Adopting class code I decided to keep current algorithm of method indexes
hashing with only some minor modifications. It's very fast anyhow it may
cause noticeable (though static) quite big memory allocation for class
definitions in applications using millions of symbols and which increase
dynamic symbol table at runtime loading new classes dynamically form .hrb,
.dll, .so or other dynamic libraries supported by Harbour. It's random
and rather impossible to exploit situation in real life anyhow I cannot
exclude it so I'd like to report it in ChangeLog. The solution is very
simple, i.e. it's enough to use classic divide et impera algorithm using
symbol numbers to find method definition anyhow it will be slower then
current one and address only very seldom hypothetical situations so I
decided to not implement it. Such static memory cost begins to be
completely unimportant in the world of 64-bit architectures and extremely
big memory address space.
The modification was sponsored by TRES company.
* src/vm/estack.c
! fixed __mvClear() in MT builds - due to stupid typo GetList variable
was removed in MT programs by CLEAR MEMORY command (__mvClear())
So far noone reported it and I've found it analyzing the code before
increasing symbol table size.
* contrib/hbwin/hbolesrv.c
* updated for new size of dynamic symbol table
* config/dos/watcom.mk
* config/linux/watcom.mk
* config/os2/watcom.mk
* config/win/watcom.mk
* src/compiler/harbour.y
* src/compiler/harbour.yyc
* utils/hbmk2/hbmk2.prg
! fix OpenWatcom disabled warning listings, numeric specifiers have
different meanings in C (wcc386) and C++ mode (wpp386) compiler
executables. "-wcd201" - not fully sure about it, is now assigned
to C mode: "unreachable code". References issue #202.
* ChangeLog.txt
! fix UTF-8 char broken by Maurizio
* config/win/global.mk
* utils/hbmk2/hbmk2.prg
! moved winmm library before kernel32. This fixes Harbour compile and
application run on Win7 and previous Windows versions if latest MinGW
is used.
; Win8+ exports timeGetTime() from both kernel32.dll and winmm.dll.
Previous windows version exports this function only from winmm.dll.
See discussion at https://github.com/msys2/MINGW-packages/issues/4984
* utils/hbmk2/hbmk2.prg
! Fixed dependency detection. Setting HB_WITH_<package>=local was ignored
if packages were detected using pkg-config
* contrib/hbexpat/3rd/expat/siphash.h
! fixed compile error for BCC <= 5.6
* rediffed
* include/harbour.hbx
* include/hbchksum.h
* src/harbour.def
* src/rtl/hbmd5.c
+ added new C function
void hb_hmac_md5( const void * key, HB_SIZE nKeyLen,
const void * message, HB_SIZE nMsgLen,
char * digest );
+ added new PRG function
HB_HMAC_MD5( <cMessage>, <cKey> ) -> <cMAC>
; HMAC MD5 is used in some authentication methods i.e. CRAM-MD5
authentication in SMTP protocol
* src/rtl/gttrm/gttrm.c
+ enable extended XTERM colors automatically when xterm-16color,
xterm-256color, xterm+256color, xterm-88color, rxvt-16color,
rxvt-256color, rxvt-98color or putty terminal is detected
+ added support for HB_GTI_SCREENDEPTH
* contrib/gtqtc/gtqtc1.cpp
+ set clipboard data also into selection buffer on platforms which
support it
+ when main clipboard buffer is empty retrieve clipboard data from
selection buffer and if it's empty too from find buffer
* include/harbour.hbx
* src/harbour.def
* src/vm/memvars.c
+ added new PRG function
__mvGetDef( <cMemvar> [, <xDefault> ] ) -> <xValue>
it works in similar way to __mvGet() but if <cMemvar> does
not exist then it returns <xDefault> or NIL instead of RTE
* contrib/hbwin/hbwin.hbx
+ added missing declarations for win_osIs10() and win_osIs81()
* contrib/hbssl/ssl.c
! fixed compilation with OpenSSL < 0.9.8k
* contrib/sddodbc/core.c
* pacified warning
* contrib/xhb/hbxml.c
* contrib/xhb/hbxml.h
! fixed CDATA terminator, it should be "]]>" instead of " ]]>"
+ added support for HBXML_STYLE_NONEWLINE flag
* src/3rd/pcre/Makefile
! typo wince -> wce
* src/main/Makefile
* use harbour.rc only in MS-Windows builds - it fixes OS2 OpenWatcom
builds
* config/global.mk
! in DOS builds check if the 'uname' exists before running it
* include/hbapigt.h
* include/hbgtcore.h
* src/rtl/hbgtcore.c
* src/rtl/inkey.c
* src/rtl/inkeyapi.c
* contrib/xhb/xhbfunc.c
+ added 3-rd parameter to hb_inkeySetText() function. When this parameter
is true then ';' is not translated to Chr( 13 ) but DOS and UNIX EOLs
are translated to Chr( 13 )
+ added logical parameter to HB_GTI_CLIPBOARDPASTE which allows to set
text without ';' translation but with platform independent EOLs
* src/rtl/memoedit.prg
* utils/hbmk2/hbmk2.prg
* contrib/hbnetio/utils/hbnetio/_console.prg
* extras/dbu/dbu52.patch
* extras/dbu/dbu53.patch
* use hb_gtInfo( HB_GTI_CLIPBOARDPASTE, .T. ) instead of
hb_gtInfo( HB_GTI_CLIPBOARDPASTE ) for pasting data from clipboard
with platform independent EOLs and ';' characters
* README.md
* config/global.mk
* contrib/gtwvw/doc/gtwvw.txt
* contrib/hbwin/tests/ole.prg
* contrib/hbzebra/tests/cairo.prg
* contrib/hbzebra/tests/harupdf.prg
* contrib/hbzebra/tests/wingdi.prg
* package/harbour-wce.spec.in
* package/harbour-win.spec.in
* package/harbour.rb
* package/harbour.spec
* package/mpkg_win.nsi
* package/winuni/mpkg_win_uni.nsi
* src/3rd/zlib/ChangeLog.txt
* src/compiler/hbusage.c
* src/pp/hbpp.c
* tests/html.prg
* changed Harbour Project website URL references to
https://harbour.github.io/
This change is very symbolic mark of time passing, but it had to be
done. Original harbour-project.org domain went out from reach
together with Phil Barnett passing away on April 16, 2015.
Respect Phil, RIP.
Phil's efforts are directly tied to The Harbour Project origins.
To memorize him, please take a tour to archived The Oasis
https://harbour.github.io/the-oasis/
* config/darwin/clang.mk
* config/darwin/gcc.mk
* config/darwin/global.mk
* config/darwin/icc.mk
* config/darwin/libs.mk
* utils/hbmk2/hbmk2.prg
* synced with Viktor's modifications in 3.4 branch:
; 2017-11-11 13:14 UTC Viktor Szakats:
* switch to call the C compiler to link dynamic libs on darwin,
which is the recommended way to do this, as suggested by Apple.
This also aligns the platform better with other *nix platforms.
'libtool' was used before, but that started having intermittent
issues around Sierra (mitigated by disabling parallel build),
which returned and got worse in High Sierra (with no remedy).
The symptom was 'ld: file not found: ' errors with the filename
not shown or appearing as garbage, then a 'libtool: internal link
edit command failed'. This was reported and will be fixed in a
future Xcode release.
Ref: Apple Radar 34944562
* config/global.mk
* config/rules.mk
+ added new user build envvar HB_USER_DCFLAGS
It allows to set C compiler parameters to compile .c code for
dynamic libraries.
* src/rtl/hbsocket.c
! fixed fcntl(F_SETFL) 3-rd parameter in hb_socketSetBlockingIO(),
By mistake I used long instead of int. it created problem on big
endian 64 bit machines.
* include/hbgtcore.h
* src/rtl/hbgtcore.c
+ added new C functions for GT programmers:
void hb_gt_BaseUnlock( PHB_GT pGT );
void hb_gt_BaseLock( PHB_GT pGT );
void hb_gtSleep( PHB_GT pGT, double dSeconds );
* src/rtl/hbgtcore.c
* src/rtl/gtcrs/gtcrs.c
* src/rtl/gtdos/gtdos.c
* src/rtl/gtgui/gtgui.c
* src/rtl/gtos2/gtos2.c
* src/rtl/gtpca/gtpca.c
* src/rtl/gtsln/gtsln.c
* src/rtl/gtstd/gtstd.c
* src/rtl/gttrm/gttrm.c
* src/rtl/gtwin/gtwin.c
* src/rtl/gtwvt/gtwvt.c
* src/rtl/gtxwc/gtxwc.c
* use new functions to unblock GT when low level TONE() code is
executed. It allows other threads to access shared GT driver
when one of them executes TONE()
* contrib/hbexpat/hbexpat.hbx
* regenerated automatically
* config/android/gcc.mk
* config/global.mk
* config/linux/gcc.mk
* config/postinst.hb
* contrib/hbpost.hbm
! removed version number from dynamic libraries for Android.
Pure Linux style dynamic library numbers in Android systems can be used
only with system libraries but it's not supported inside .apk packages
so our dynamic libraries were unusable for Android programmers unless
someone plans to install more then one version of Harbour dynamic
libraries as Android system libraries. It's rather unusual situation
and I believe that in such case he can easy create such libraries
building Harbour for Linux with NDK.
* enabled by default building contrib dynamic libraries in Harbour
Android build.
+ added -Wl,--no-undefined to linker parameters when dynamic libraries
are created to verify if dynamic libraries can be used in Android .apk
packages during Harbour build process.
; After above modification dynamic (*.so) libraries created in Harbour
build process can be used in .apk packages. It means that projects
like HDroidGUI do not longer need their own custom versions of
libharbour.so but can use the one from standard Harbour Android build.
They can also use Harbour contrib dynamic libraries.
; TODO: add support for automatic NDK detection in Harbour build process
; TODO: add to HBMK2 basic support for generating .apk packages
* contrib/gtqtc/gtqtc.hbp
* disabled dynamic GTQTC library in Android builds until we set explicit
bindings with QT/C++ dynamic libs
* src/common/hbdate.c
* implemented monotonic timers in POSIX and MS-Windows builds
* config/wce/global.mk
* config/wce/mingwarm.mk
* config/win/global.mk
* utils/hbmk2/hbmk2.prg
* added winmm/mmtimer to list of system libraries - required
for timeGetTime()
* ChangeLog.txt
! typos
* config/dyn.mk
* config/win/mingw.mk
* src/dynlib/2nd/Makefile
* src/dynlib/Makefile
+ src/harbour.def
+ use .def file to specify public symbols of harbour.dll
for more details, see:
f238e5f81fb2c9e4a63b
; NOTE: please make sure to add any new public (HB_EXPORT)
symbols to this list. Ordinals are not significant
ATM so the best is to keep alphabetical order.
* include/hbapifs.h
* src/common/hbfsapi.c
+ added automatic file handle table resizing to hb_fsOS2DosOpenL()
+ added new C function: hb_fsOS2DosOpen() which is wrapper to DosOpen()
with automatic file handle table resizing.
Please remember that unlike hb_fsOS2DosOpenL() this function is
pure wrapper to DosOpen() so it does not make file name conversions
and does not set hb_fsError().
* src/rtl/filesys.c
* src/rtl/hbcom.c
* src/rtl/hbproces.c
* use hb_fsOS2DosOpen() instead of DosOpen()
* src/vm/cmdarg.c
* set the initial size of file handle table to 256 in OS2 OpenWatcom
builds if user does not set it explicitly by //F:<n> switch
* config/global.mk
- removed set HARBOUR=F:100 - it's not necessary with automatic FHT
resizing
; Please test it in real OS2 environment
* *
% remove brandings and homepage [1] from copyright header. Pass 1 - using script.
[1] nobody has access to it anymore AFAIK - and it's also just
a redirect since long
! update url in copyright header
; this should make the diff between 3.4 and 3.2 easier to manage
* config/global.mk
* set HARBOUR=F:100 during build process in OS2 builds - it increases
maximum number of open handles per process from 20 to 100 so it should
be possible to use -j<n> switch during Harbour compilation - please
test, i.e.:
os2-make -j3
* contrib/xhb/hbcompat.ch
! fixed pp rules for Str(,,, <lStrip> ) translation
* include/hbapifs.h
* src/rtl/filesys.c
+ added new C function:
HB_FHANDLE hb_fsOpenEx( const char * pszFileName, HB_FATTR nAttr,
HB_USHORT uiFlags );
* minor cleanup
* include/hbmemory.ch
* src/vm/fm.c
+ added two new actions for Memory() function:
HB_MEM_STATISTICS - return non 0 value if FM statistic is enabled
HB_MEM_ISLIMIT - return non 0 value if used memory limit is
supported
+ added new PRG function:
__fm_allocLimit( [ <nNewLimit> ] ) -> <nPrevLimit>
It allows to set limit for maximum used memory in some memory
managers, -1 means no limit.
Now it works with DLMALLOC and in ST mode it's limit for memory
allocated from system for whole application. In MT mode when
HB_FM_DLMT_ALLOC (default for DLMALLOC) is enabled it's limit for
single MSPACE (Harbour allocates 16 MSPACES and balance them
between threads to improve scalability) so it's rather per thread
limit. If memory statistic module is enabled during Harbour build
process then this limit works with any memory manager and defines
limit for total memory allocated by Harbour application regardles
of MT or ST mode.
* src/vm/hvm.c
* use HB_MEM_STATISTICS instead of HB_MEM_USEDMAX to check if memory
statistic module is enabled
* include/hbsocket.h
* src/rtl/hbsockhb.c
+ added new C function:
HB_BOOL hb_sockexItemReplace( PHB_ITEM pItem, PHB_SOCKEX pSock );
* contrib/hbssl/ssl_sock.c
+ replace passed socket structure to hb_socketNewSSL_connect() and
hb_socketNewSSL_accept() with new one using SSL filter if it was
passed by reference, current syntax is:
hb_socketNewSSL_connect( [@]<pSocket>, <pSSL> [, <nTimeout> ] )
-> <pSocketSSL>
hb_socketNewSSL_accept( [@]<pSocket>, <pSSL> [, <nTimeout> ] )
-> <pSocketSSL>
* contrib/hbssl/hbssl.hbm
* contrib/hbssl/hbssl.hbx
+ contrib/hbssl/ssl_hbcon.prg
+ added new PRG functions which can be used for fast initialization of
SSL connection:
hb_SSL_new() -> <pSSL>
hb_SSL_connect_inet( <pSocket>, [ <nTimeOut> ], [ @<cInfo> ] )
-> <lConnected>
hb_SSL_connect_socket( <pSocket>, [ <nTimeOut> ], [ @<cInfo> ] )
-> <lConnected>
They do not need any addiitonal initialization code and can be called
as first and the only SSL functions in user code.
* contrib/hbtip/mail.prg
! fixed bug reported by Lorenzo - thanks
* use hb_MemoWrit() in :detachFile() to honor Harbour File IO API
* cleanup
* src/common/hbffind.c
* src/rtl/gtos2/gtos2.c
* src/rtl/hbproces.c
* cleaned DosAllocMem() flags
* src/common/hbfsapi.c
* src/rtl/hbproces.c
* pacified OS2 GCC warnings
* config/global.mk
* show information about HB_MT build parameter if set by user
+ src/3rd/hbdossrl/Makefile
+ src/3rd/hbdossrl/serial.c
+ src/3rd/hbdossrl/serial.h
+ src/3rd/hbdossrl/README
+ added DOS Serial Library - it's much cleaner and simpler then COMLib
we used so far in DOS builds. It also supports hardware and software
flow control. Many thanks for Karl Stenerud for his wonderful job.
* src/rtl/hbcom.c
+ added support for DOS Serial Library used as low level backend in
Harbour DOS builds.
* config/dos/djgpp.mk
* config/dos/watcom.mk
* config/dyn.mk
* config/lib.mk
* src/3rd/Makefile
* src/Makefile
* utils/hbmk2/hbmk2.hbp
* utils/hbmk2/hbmk2.prg
* use DOS Serial Library (hbdossrl) instead of COMLib (hbpmcom)
* config/dos/watcom.mk
* config/win/watcom.mk
* config/linux/watcom.mk
! enabled -bd OpenWatcom switch for code compiled as part of dynamic
libraries
* use CauseWay as default DOS extender for dynamic DOS builds
* config/dyn.mk
* config/lib.mk
* src/Makefile
! fixed list of libraries used to create Harbour DLL in DOS builds
* config/bin.mk
* src/vm/Makefile
* create hbmainstd library for OpenWatcom DOS shared builds
* src/vm/maindllh.c
+ added DLL entry function for CauseWay DLLs in OpenWatcom builds
* src/vm/main.c
* include maindllh.c in OpenWatcom DOS shared builds
* utils/hbmk2/hbmk2.prg
+ added support for dynamic binaries in DOS OpenWatcom builds.
Support for CauseWay DLLs is still broken in current OpenWatcom
builds so it will have to wait for the fix to be usable.
* src/vm/dynlibhb.c
+ added support for dynamic libraries to OpenWatcom DOS builds.
Now it's enabled only in harbour.dll due to problems with
CW and current OW.
* src/3rd/zlib/zconf.h
* src/3rd/zlib/zlib.dif
* use OS2 patch for exporting ZLIB symbols also in DOS builds
* src/rdd/dbf1.c
* pacified warning
* config/os2/watcom.mk
+ added -bd to Watcom C switches used to compile files for Harbour DLL.
It should fix the problem with OpenWatcom binaries using harbour.dll.
* config/win/msvc.mk
* utils/hbmk2/hbmk2.prg
* disabled -nologo option used with resource compiler in MSVC builds.
Compiler version is not enough to detect supported parameters when
Platform SDK rc.exe is used.
* src/rtl/hbproces.c
! do not use SetHandleInformation() in WinCE builds
* config/wce/global.mk
* utils/hbmk2/hbmk2.prg
! added iphlpapi to WinCE builds
