FiveTech Support Forums

OK, I can see several developers are using this capability and they find it valuable. But I still don't understand it's advantages.

I can compile a large EXE in less than a minute. So, maybe I could save a few seconds if I didn't have to recompile the EXE, just the new PRG. I don't think a few seconds saving is great reason for using this technique.

Perhaps it is a memory issue with large apps? I assume the compiled code is run, then removed from memory? OK, but aren't large EXEs partially paged out of memory when segments are not being used?

Is there some other capability that this technique provides that is better than using a single EXE?

Or, is there some feature this provides that is not available with a single EXE?

Also, I see a quality control issue. How can one be sure that the client's site has all the same compiled modules that the developer's site does? I can see how a developer might test everything at their site (and all is OK) but then one or more modules are not updated on the client's site. So, it would seem that all testing would have to be done on both the developer's site then again on the client's site.

James,

An EXE can use some data (config, settings, etc) to modify its behavior. We are used to this.

But if you totally want to transform your app into something new, you need code. Objects are data plus behaviors (defined by their classes). You are an expert object oriented developer, so you already know this

Behaviors are defined by methods acting on the data as a unity. Encapsulation tell us that data and methods need each other. They don't exist separately.

We can add data, we can modify it. But how to add code ?

Our traditional idea is to build a new EXE and put some more code into it. But what if you can't modify the EXE ? How to do it then ?

And thats where hbcplr.lib comes to help. The EXE can use PRG code and transform it into executable code, and then the app changes completely. Radically

And if you inherit a new class and redefine some methods, then you have a new class and there you can do what you want. So the possibilities are endless.

Now let me give you an example. An app that many of us have used: dBase. dBase was a closed EXE but had the ability to accept PRG code and make it run, and two apps built with dBase could act totally different, right ? Why ? Now compare dBase behavior with my above explanation and you will see the similarities

Antonio,

Enrico Maria Giordano wrote:Antonio,

Antonio Linares wrote:xHarbour does not provide it. You may ask in the xHarbour devel list. I wish I were wrong

Done.

EMG

This is from Saulius:

Hi Enrico,

Have you tried functions:
__HRBRUN
__HRBLOAD
__HRBDO
__HRBUNLOAD
__HRBGETFU
__HRBDOFU

Saulius

And this is my answer:

Thank you. If I understood correctly, the above functions are for HRB file not for PRG file. I asked something to compile and execute PRG file during runtime.

And this is from Saulius again:

Exactly!
You can compile with xharbour.exe prg file into hrb file and then execute!
During runtime

So, it seems that there is nothing to compile a PRG within the EXE. We have to call HARBOUR.EXE.

But please, look at this from Marcos Antonio Gambeta:

Hi Enrico,

Harbour have a library, but there are a limitation: the code is pure GPL (without Harbour exception). Can be used only in open source applications.

We cannot include the Harbour compiler in proprietary applications.

See the headers of the files \xharbour\source\compiler\*.*

What do you think?

EMG

Enrico,

We have to fully respect the license, so if you want to use this powerful feature, then you must turn your app open source

And I don't see a problem in that

Antonio,

dBase: Yes, I wrote lots of code in dBase. Then Clipper came out and most of us immediately switched to it. One of the main reasons was that the app could be distributed to users without them having to own a copy of dBase. Another reason was so that the code would remain proprietary. Nobody could just modify the code themselves and/or resell as their own app.

In this case the Harbour.exe is free, but we would still be exposing the source if we provide the PRGs. But it does seem that we could compile them first into a compiled form and then distribute that instead. OK, this is somewhat better than the dBase situation.

However, in the situation where you have main EXE which you don't have access to (maybe not written by you), I don't see how you can add something new to a menu or button in the main EXE so as to call your new routine. I do see that you could write a new app which could be perhaps called by the EXE indirectly (something like "whatever.exe myNew.HBR") which would have to be called by the OS outside the existing EXE (like on the Start menu). You could, of course, alternatively, just add a new EXE which could add to the existing closed EXE.

If you had written the original EXE then it would had to have been designed so that you could add new routines. It would have to be at least partially data driven with menus stored in a file, so that you could add to them without recompiling the EXE.

So this seems like resurrecting the past. Granted it is an alternate way to do things, but I still don't see any great advantages. But, some developers seem to really like this, and that's great. Perhaps I will see a use for it as time goes on...

James,

One correction. Users did not need to own dBase, nor did you have to provide source code. We supplied them with a RunTime license, and the code was "encrypted" so it could only run under the license, and could not be modified. I think I still have some disks here with the Run Time licenses from Ashton Tate.

I suppose the benefit here would be if we put in some hooks, and kept the .prg in encrypted memo files. Thus we could call the modified code, and use it at runtime. We can keep the .exe stable this way, and simply add the customized capabilities. I'm not doing it, but in theory I can see a benefit.

Tim

Enrico,

I think the main point here is that you like what you are using, and you don't want to change. That's OK.

I will try to be quite clear on why I have decided to make this move, and it's one word: Antonio. My focus is not on Harbour or xHarbour, but rather using the most current tools. IF I were to have someone interested in buying my company, they would not want to hear Borland, or Pelles C, Harbour, or xHarbour. They do want to hear Microsoft. While all those other brands are relatively unknown, when they hear the product is built with Microsoft C, in Visual Studio 2013, they are comfortable. At my age, that is an important issue.

So why did I say Antonio ? He has been here to provide support for many years, and he continues to deliver day after day. I appreciate that support, and I want to make it easiest on him, so I use what he uses. I don't get that support from any other place in the xBase world. I've been doing this since 1982 ( and it was my 2nd career back then ). Antonio uses Harbour, and the developers there will cooperate with him. xHarbour was a variant and frankly those folks were not supportive of his work. Still, he provided a product for both environments.

I think people are starting to see what I shared over a year ago. Microsoft is changing their approach. Visual Studio is an open platform, it is now free to non-enterprise developers, it is updated monthly ( or more ), and it is multi=platform. In addition, .NET is now going to open source, and cross platform. In time, I see no reason why we won't be able to build FW projects for .NET. I realize people will immediately jump in and challenge this based on past history, but there is a new path at Microsoft and those of us who have taken the time to be involved with some of their leaders can see it.

So, my goal is to have my product(s) and company positioned to be appealing to someone who might like to take over the work in the future. That will only happen if I use the latest tools upon which a younger generation has been trained.

At least, that is the way I see it, and why I spent the time doing the transition. Frankly, it wasn't hard, and as I said, my source code builds with Harbour, or xHarbour ( .com ) with absolutely the same base code used for both, but called by the different build tools.

Tim

James,

The new products that I want to build for Android and iOS will use hbcplr.lib

This way users can download an application from Android/iOS markets and install them on their devices. No need to download new builds. They will all have the same app from the markets.

And then from the same device you will be able to code an app, and to modify it and you will not have the need to rebuild the application

Thats why I said that I see them as modern dBase for the Android/iOS. You can get code from the email on a tablet, or from an FTP, or from a web, or write it in site (the tablet). Then you can save that code as encrypted in your device, or you could provide a code to your user that will only allow him to run it on his device.

Those tools could give us the power to build apps for tablets without having to build apps from Google and Apple development environments. No need to learn Java (Android) neither to learn ObjectiveC (iOS). No need to publish your apps in the market and you can upgrade your customers just sending them an encrypted PRG that those apps will run.

All that would be impossible to exist without the power of hbcplr.lib

Antonio, James,

James Bott wrote:I do see that you could write a new app which could be perhaps called by the EXE indirectly (something like "whatever.exe myNew.HBR")

If we are talking about HRB file then xHarbour is able to handle them with the functions I reported (__HRBRUN(), etc.).

EMG

Tim,

TimStone wrote:I think the main point here is that you like what you are using, and you don't want to change. That's OK.

What makes you think so? If it were true I wouldn't try to adapt my applications to Harbour.

TimStone wrote:They do want to hear Microsoft.

Change C compiler is another story. I can change C compiler without problem. The problem now is Harbour. I'm trying to test it but I still get strange errors. But I'm keep trying...

EMG

Antonio,

Antonio Linares wrote:The new products that I want to build for Android and iOS will use hbcplr.lib

So there is no problem at all. I already used Harbour for FWPPC. I can use it for new platforms. My current problem is recompiling my applications with Harbour to test if there are real improvements. If I succeed, I planned to give the applications to my customers for a real test.

EMG

Enrico,

yes, you can do similar things using HRB files, but imagine that you want to create them from a tablet. Thats impossible, unless you have harbour.exe in the tablet. Of course, you can email them, download them, etc.

But there is no way to create them in the tablet without harbour.exe unless you use hbclpr.lib

Tim,

One correction. Users did not need to own dBase, nor did you have to provide source code. We supplied them with a RunTime license, and the code was "encrypted" so it could only run under the license, and could not be modified. I think I still have some disks here with the Run Time licenses from Ashton Tate.

My memory is vague, but if I remember correctly, the runtime licenses cost and Clipper EXE's didn't.

Also, I seem to remember there was a decompiler for the "encrypted" modules.

Anyway, this is all water under the bridge now.

Antonio,

The new products that I want to build for Android and iOS will use hbcplr.lib

This way users can download an application from Android/iOS markets and install them on their devices. No need to download new builds. They will all have the same app from the markets.

And then from the same device you will be able to code an app, and to modify it and you will not have the need to rebuild the application.

Ok, now you're talking. This is a whole new concept. We all do need to get into the mobile market. Now I am all ears!

Explain how we can run harbor libs under Android and iOS. I am guessing they have to be compiled using Visual Studio? I don't even know what questions to ask about this capability.

Enrico,

If we are talking about HRB file then xHarbour is able to handle them with the functions I reported (__HRBRUN(), etc.).

OK, I stand corrected on the syntax and I get your point that xHarbour can do this too.

My point still is that the original EXE would have to be designed to run external modules. It would have to be able to do:

__HRBRUN( cFilename )

Where cFilename is the name of an external module. And it seems that you would still need a data driven menu design so you could modify the menu without modifying the EXE.