Author Topic: BCX Runtime.lib  (Read 213 times)

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
BCX Runtime.lib
« on: August 07, 2020, 03:44:45 PM »
Dear Group,

I was able to find a 2004 version of BCX that produced the files needed to create BcxRt.lib but it only supported LccWin32 which is obviously not acceptable anymore.

I am becoming convinced that the BcxRt.lib generating feature has been broken in one way or another for the last 15 years.  Unless someone in this group can convince me that I'm wrong, I'm strongly considering removing that "feature" from BCX altogether.
 
Please share any experience you have on this subject.


Robert

  • Sr. Member
  • ****
  • Posts: 448
    • View Profile
Re: BCX Runtime.lib
« Reply #1 on: August 07, 2020, 06:11:03 PM »
Dear Group,

I was able to find a 2004 version of BCX that produced the files needed to create BcxRt.lib but it only supported LccWin32 which is obviously not acceptable anymore.

I am becoming convinced that the BcxRt.lib generating feature has been broken in one way or another for the last 15 years.  Unless someone in this group can convince me that I'm wrong, I'm strongly considering removing that "feature" from BCX altogether.
 
Please share any experience you have on this subject.

Hi MrBCX:

I think that the

Can't open file BCXRT.c

is a false flag and would be trivial to fix.

The batch file to compile the .lib is another story. It would take days to bring it up to date.

The updating as revisions are made to BCX is yet more work.

I think you know where I'm going with this ...

Nobody's using it, Toss it out !

We can replace it with Vic's famous Biscuits and Gravy recipe.

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: BCX Runtime.lib
« Reply #2 on: August 07, 2020, 07:08:12 PM »
Robert,

Thank you for your opinion, your vote, and your ability to put the aroma of biscuits and gravy in my head, so late in the day.

There is certainly more in play than a false flag.  I tested more than a dozen versions of BCX, going back to 2004, trying to get either Pelles or Lccwin to cooperate, as those would have been the dominant compilers in use with BCX at that time.  The result of my tests was one disappointment after another.  C'est la Vie ...

I'll allow time for other parties to chime in before I make any drastic moves.
« Last Edit: August 07, 2020, 07:20:07 PM by MrBcx »

Robert

  • Sr. Member
  • ****
  • Posts: 448
    • View Profile
Re: BCX Runtime.lib
« Reply #3 on: August 07, 2020, 10:48:44 PM »
Robert,

Thank you for your opinion, your vote, and your ability to put the aroma of biscuits and gravy in my head, so late in the day.

There is certainly more in play than a false flag.  I tested more than a dozen versions of BCX, going back to 2004, trying to get either Pelles or Lccwin to cooperate, as those would have been the dominant compilers in use with BCX at that time.  The result of my tests was one disappointment after another.  C'est la Vie ...

I'll allow time for other parties to chime in before I make any drastic moves.

Hi MrBCX:

My position has not changed. If no one is using it, get rid of it.

Having said that, what I have found is that the last BCX version that built BcxRt.lib without errors was BCX 7.0.7.

Code: [Select]

C:\dev\BCX\BCX\rtlib>BuildRTL P
Creating BCX Runtime Library for PellesC...
BCX-32: BASIC to C/C++ Translator by Kevin Diggins (c) 1999 - 2013
BCX-32 Version BCX 7.0.7pc (2013/08/11)
[Lines In: 2] [Lines Out: 7379] [Statements: 29] [Time: 0.02 sec's]
BCX Created Runtime Library Files
        1 file(s) copied.
        1 file(s) copied.
Setting 32-bit environment for Pelles C...
        1 file(s) copied.
Finished!


The BuildRTL.bat file required minor tweaking to the includes on the Pelles command line. Other than the required path modifications that was all that was needed to build the library.

BCX 7.0.8 changed OSVERSION to return an ENUM and that ENUM was not wrapped in a IF Use_Library flag so in BCX 7.0.8 and up the OSVERSION.c object is not built but the library still is built without OSVERSION. BCX 7.3.1 built the library same as 7.0.8, everything but OSVERSION.

I suspect that the if the OSVERSION ENUM was fixed along with the omissions from the const char * shemozzle, the latest BCX would build the BCXRT.lib.

But, in the back of my mind is still that selfish little devil whispering, "You do all that work, you build a library, and those vultures that contribute nothing rip it off for their own selfish ends without contributing anything and even worse not even having to do ANY work to get it."  That feeling has been there from the beginning of Vic's project to build the BCXRT library.

Even so, that niggling little retards' whispers are drowned out by Indira Gandhi's saying "There are two kinds of people, those who do the work and those who take the credit. Try to be in the first group; there is less competition there."


jcfuller

  • Full Member
  • ***
  • Posts: 167
    • View Profile
Re: BCX Runtime.lib
« Reply #4 on: August 08, 2020, 05:23:45 AM »
Kevin,
  Drop it. I did early on with the bc9 port.
It has been (and probably would be again) exploited by the ......

James

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: BCX Runtime.lib
« Reply #5 on: August 08, 2020, 10:29:01 AM »

The BuildRTL.bat file required minor tweaking to the includes on the Pelles command line. Other than the required path modifications that was all that was needed to build the library.

BCX 7.0.8 changed OSVERSION to return an ENUM and that ENUM was not wrapped in a IF Use_Library flag so in BCX 7.0.8 and up the OSVERSION.c object is not built but the library still is built without OSVERSION. BCX 7.3.1 built the library same as 7.0.8, everything but OSVERSION.

I suspect that the if the OSVERSION ENUM was fixed along with the omissions from the const char * shemozzle, the latest BCX would build the BCXRT.lib.

But, in the back of my mind is still that selfish little devil whispering, "You do all that work, you build a library, and those vultures that contribute nothing rip it off for their own selfish ends without contributing anything and even worse not even having to do ANY work to get it."  That feeling has been there from the beginning of Vic's project to build the BCXRT library.

Even so, that niggling little retards' whispers are drowned out by Indira Gandhi's saying "There are two kinds of people, those who do the work and those who take the credit. Try to be in the first group; there is less competition there."

Robert - thank you for that.  I appreciate your technical and philosophical points on the subject.  And where my soul warms to the idea of jumping in line behind Gandi, the cold and rational side of me says, "My patience and motivation grows thinner from needing to work around some constantly tedious and unfulfilling aspects of BCX's internal source code."

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: BCX Runtime.lib
« Reply #6 on: August 08, 2020, 10:29:42 AM »
I have a prelim version of 753 which eliminates everything related to $PROJECT and BCXRT.lib/dll. 
I'm keeping an open mind to any (so far, unexpressed) opposing viewpoints on the subject.

These have been removed from the switches

[-h] Generate HEADER file for use with $Projects
[-l] Create Runtime LIBRARY source and header Files


This:
Code: [Select]
GLOBAL  Use_LoadLibraryError        ' Use error routine when loading libraries
GLOBAL  LibraryErrorLog$            ' [Path\][Name] of error log for loading libraries
GLOBAL  Use_Library AS BOOL         ' Vic McClung for Building Runtime Library
GLOBAL  Use_Project AS BOOL         ' Vic McClung for $PROJECT Support
GLOBAL  szProject$
GLOBAL  Gen_Header AS BOOL          ' Vic McClung for $Project Support
GLOBAL  Use_Dll AS BOOL             ' Vic McClung for Building BCXRT.DLL
GLOBAL  Project_Main$               ' main file in project
GLOBAL  Project_List$               ' list of files in project
GLOBAL  Project_Path$               ' path for project output files, i.e. .h;.c;.cpp
GLOBAL  NoRT AS BOOL                ' No Runtime
GLOBAL  NoKill AS BOOL              ' don't erase BCXRT.C file - used for debugging runtime

is now this:

Code: [Select]
GLOBAL  Use_LoadLibraryError        ' Use error routine when loading libraries
GLOBAL  LibraryErrorLog$            ' [Path\][Name] of error log for loading libraries
GLOBAL  szProject$
GLOBAL  Project_Main$               ' main file in project
GLOBAL  Project_List$               ' list of files in project

This

BCX BASIC to C/C++ Translator (c) 1999-2020 by Kevin Diggins
Version 7.5.2 (2020/08/08)  Compiled for 64-bit Windows using MS Visual C++
[Lines In: 32894] [Lines Out: 42521] [Statements: 30657] [Time: 0.75 sec's]
BCX translated [Bc.Bas] to [Bc.C] for a C Compiler

is now this

BCX BASIC to C/C++ Translator (c) 1999-2020 by Kevin Diggins
Version 7.5.3 (2020/08/08)  Compiled for 64-bit Windows using MS Visual C++
[Lines In: 31093] [Lines Out: 38605] [Statements: 27824] [Time: 0.69 sec's]
BCX translated [Bc.Bas] to [Bc.C] for a C Compiler


There's likely more cleanup to be done and then regression tests but I like seeing sanity restored to code:

This

Code: [Select]
  IF Use_Lpad THEN
    FPRINT FP_WRITE, "char *lpad (LPCTSTR a, int L, int c)"
    FPRINT FP_WRITE, "{"
    FPRINT FP_WRITE, "  char *strtmp;"
    FPRINT FP_WRITE, "  L=L-strlen(a);"
    FPRINT FP_WRITE, "  if(L<1) return (char*)a;"
    FPRINT FP_WRITE, "  strtmp = BCX_TmpStr(L);"
    FPRINT FP_WRITE, "  memset(strtmp,c,L);"
    FPRINT FP_WRITE, "  return strcat(strtmp,a);"
    FPRINT FP_WRITE, "}\n\n"
  END IF

instead of this

Code: [Select]
  IF Use_Lpad THEN
    IF Use_Library THEN FPRINT FP_WRITE, "// BCXRTLIB: lpad"
    FPRINT FP_WRITE, "char *lpad (LPCTSTR a, int L, int c)"
    FPRINT FP_WRITE, "{"
    FPRINT FP_WRITE, "  char *strtmp;"
    FPRINT FP_WRITE, "  L=L-strlen(a);"
    FPRINT FP_WRITE, "  if(L<1) return (char*)a;"
    FPRINT FP_WRITE, "  strtmp = BCX_TmpStr(L);"
    FPRINT FP_WRITE, "  memset(strtmp,c,L);"
    FPRINT FP_WRITE, "  return strcat(strtmp,a);"
    FPRINT FP_WRITE, sENDBCXRTLIB$
  END IF


I shall continue on for now ...
« Last Edit: August 08, 2020, 12:10:14 PM by MrBcx »

dgarner

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: BCX Runtime.lib
« Reply #7 on: August 08, 2020, 03:15:17 PM »
Team,

I was surprised to learn of the feature when it appeared, even more surprised when it was later being asked about like it was a core part of the project, and would not miss it if it vanished. 

I think John Jacques and I were the inspiration for it becoming a thing, in the first place.  I was attempting to share my understanding of how C works, and he did his thing to grasp the concepts.  Others, evidently, found more use for it than we did and made it a thing.

I'm still hoping to dive into the internals of BCX "real soon now".  If BCX can be simplified, before I start that effort, that would suite me "just fine".

Thanks to all those who do the work.

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 538
    • View Profile
Re: BCX Runtime.lib
« Reply #8 on: August 08, 2020, 07:19:56 PM »
Update ...

Well, as sometimes happens, I learned the hard way that I was a little too aggressive with my code scalpel.

My challenge was that the code that creates BCXRT.LIB/.DLL was commingled with some of the $PROJECT code. 

When I excised the BCXRT and $Project code, I broke $PRJ / $PRJUSE ... Arrrgh!

Let's just say my new found insight is making this easier the SECOND time around.