Harbour ChangeLog - Relevant for HMG interest

Harbour, MingW related news.

Moderator: Rathinagiri

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Harbour ChangeLog - Relevant for HMG interest

Post by Pablo César » Mon Jul 06, 2015 9:39 pm

Sharing knowledge about harbour to make our P-O-V.

Two Harbour versions:
https://github.com/vszakats/harbour-core
http://sourceforge.net/projects/harbour-project/files/

I have got some more info about Przemyslaw Czerpak (Harbour 3.2) and Viktor Szakats (Harbour 3.4) Harbour versions and both is quite the same. All keeping Clipper 100% compatible but 3.4 has more than 2000 commits more and in HB_LEGACY_LEVEL5, obsolete functions must replaced at our source codes, in case. But this is normal thing.

What is HB_LEGACY_LEVEL ?
Klas Engwall wrote:There are two HB_LEGACY_LEVEL[n] macros #defined in include\hbsetup.ch,
HB_LEGACY_LEVEL4 and HB_LEGACY_LEVEL5

Any code guarded with one of those macros will be compiled, code guarded with lower HB_LEGACY_LEVEL[n] macros will be skipped when Harbour itself is built. Those portions of the Harbour source code can now be removed, if they still exist, since they make no difference in current Harbour builds. When, in the future, the HB_LEGACY_LEVEL4 macro is removed from
the header file, sections of code marked with that macro will then be ignored while building Harbour.

So this is a way to say that "this code will exist for a while but will be removed after the next stable release" or "... after the second stable release from now", etc. New HB_LEGACY_LEVEL6, HB_LEGACY_LEVEL7 etc macros will set the date for deprecating other code sections in the
future.

There is no magic in it, just code that depends on that a certain macro is #defined, just like anything else guarded with an #ifdef

Regards,
Klas
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Post by Pablo César » Tue Jul 07, 2015 9:39 pm

Hi all,

Another version is available from Viktor Szakats: Harbour 3.4 as follows:
2015-07-07 18:35 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
  * appveyor.yml
    + re-enable contribs

  * package/mpkg_ts.hb
  * package/mpkg_win.bat
    * minor cleanups

  ; Harbour 3.4 Windows builds are now reproducible/deterministic,
    meaning that builds made from the same Git commit hash will
    generate bit-identical (7z.exe) distribution packages. Given
    of course equal settings and dependencies. With automated
    Appveyor CI builds dependencies are also controlled by the
    repository itself, so those builds are guaranteed to be
    deterministic always. It has been tested with mingw 32-bit
    and mingw 64-bit (and dual builds) should be supported as well.
    Other C compilers may or may not work depending on what/if
    non-deterministic metadata is stored inside their libraries.
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Post by Pablo César » Wed Jul 22, 2015 5:37 pm

In accordance with the technical note from Microsoft:

https://msdn.microsoft.com/en-us/librar ... 25492.aspx
This is because MS deprecated GetVersion*() functions, so they
would return false/emulated values on or above Win8 anyway.
ChangeLog Harbour 3.4
2015-07-22 12:23 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
  * src/common/hbver.c
    ! fix to previous modification (Win10 and new server detection)
    + refactor to not rely on GetVersion*() calls except for
      detecting legacy Windows versions and build number and
      service pack string on non-legacy Windows versions.
    % do not try to detect Wine on WinCE

  * contrib/hbwin/tests/os.prg
  * contrib/hbwin/win_osc.c
    * minor cleanups

2015-07-22 11:14 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
  * appveyor.yml
    * temply enable OS version to test it

  * src/common/hbver.c
    * rework to use fewer deprecated GetVersion*() calls (2 to go)
    + recognize Win10, Server 2016, 8.1, Server 2012 R2 versions

  * contrib/hbwin/win_osc.c
    ! update Win10 detection based final official docs

2015-07-22 10:30 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
  * src/common/hbver.c
    ! follow MSDN advice in:
         https://msdn.microsoft.com/en-us/librar ... 25492.aspx
      "If you are testing the major version, you must also test the
       minor version and the service pack major and minor versions."
    * replace ZeroMemory() with memset()

  * contrib/hbwin/win_osc.c
    * convert these functions to return emulated values with HB_LEGACY_LEVEL4:
      - return .T. on all NT platforms: WIN_OSISNT351(), WIN_OSISNT4()
      - return .T. on all Win9x platforms: WIN_OSIS95(), WIN_OSIS98(), WIN_OSISME()
      - build number will be zero, service pack an empty string and
        versions will be emulated: WIN_OSVERSIONINFO()
      This is because MS deprecated GetVersion*() functions, so they
      would return false/emulated values on or above Win8 anyway.
Keeping you informed. :)
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

EduardoLuis
Posts: 648
Joined: Tue Jun 04, 2013 6:33 pm
Location: Argentina
Has thanked: 1 time
Been thanked: 60 times

Post by EduardoLuis » Wed Jul 22, 2015 7:41 pm

Thanks Pablo for your great job keeping all us informed.-
Eduardo

User avatar
serge_girard
Posts: 2311
Joined: Sun Nov 25, 2012 2:44 pm
DBs Used: 1 MySQL - MariaDB
2 DBF
Location: Belgium
Has thanked: 555 times
Been thanked: 116 times
Contact:

Post by serge_girard » Thu Jul 23, 2015 7:31 am

Thanks Pablo!

Serge

User avatar
bpd2000
Posts: 1074
Joined: Sat Sep 10, 2011 4:07 am
Location: India
Has thanked: 196 times
Been thanked: 95 times

Post by bpd2000 » Thu Jul 23, 2015 7:59 am

Hi Pablo!
Important thread
Continue
BPD
Convert Dream into Reality through HMG

User avatar
Pablo César
Posts: 4059
Joined: Wed Sep 08, 2010 1:18 pm
Location: Curitiba - Brasil
Has thanked: 100 times
Been thanked: 182 times

Post by Pablo César » Wed Sep 28, 2016 12:15 pm

Probably most of problem about memory leakage can be solved from Habour core.

Code: Select all

2016-09-27 11:54 UTC+0200 Viktor Szakats (vszakats users.noreply.github.com)
  * contrib/hbhttpd/core.prg
  * extras/httpsrv/uhttpd.prg
    ! fix four Len() vs. hb_BLen() unicode bugs
HMGing a better world
"Matter tells space how to curve, space tells matter how to move."
Albert Einstein

User avatar
andyglezl
Posts: 1149
Joined: Fri Oct 26, 2012 7:58 pm
Location: Guadalajara Jalisco, MX
Has thanked: 35 times
Been thanked: 68 times
Contact:

Post by andyglezl » Wed Sep 28, 2016 1:26 pm

Gracias !
Andrés González López
Desde Guadalajara, Jalisco. México.

User avatar
srvet_claudio
Posts: 2044
Joined: Thu Feb 25, 2010 8:43 pm
Location: Uruguay
Has thanked: 35 times
Been thanked: 146 times
Contact:

Post by srvet_claudio » Thu Sep 29, 2016 2:31 am

I have been thinking about this matter, but not if it worth upgrading to fork 3.4.

What you think about this still with Harbour version 3.2 or changes to version 3.4 ?
Best regards.
Dr. Claudio Soto
(from Uruguay)
http://srvet.blogspot.com

User avatar
apais
Posts: 305
Joined: Fri Aug 01, 2008 6:03 pm
Location: uruguay
Has thanked: 49 times
Been thanked: 28 times
Contact:

Post by apais » Thu Sep 29, 2016 5:05 am

3.4 is not an upgrade but a fork
It was make so Viktor has not to explain anything to anybody and implement whatever he likes in the compiler.
Usefull things are synced by Przemek to 3.2.
Moving to 3.4 means subyugate HMG to a one man's project.
And we all know he has a problematic personallity

Just wandering...

Post Reply