I'm still pretty new to Xbase++, but everything I've done
so far has required that lots of DLL's be present when I
run my programs.  Is there a way to compile a single "EXE"
like we could in Clipper which will not require any DLL's
at all?  I know it would probably be very large, but that
is what I want.  Can anyone please help with a sample .XPJ
or something?  I would greatly appreciate it.
- Thanks alot.
Randy Howe

you can't made a standalone executable with xbase++ as you can in other
32bit clipper compiler  (xharbour)

"Randy Howe" <r.howe@verizon.net> ha scritto nel messaggio
news:fLACqh%23dEHA.6512@S15147418...
> I'm still pretty new to Xbase++, but everything I've done
> so far has required that lots of DLL's be present when I
> run my programs.  Is there a way to compile a single "EXE"
> like we could in Clipper which will not require any DLL's
> at all?  I know it would probably be very large, but that
> is what I want.  Can anyone please help with a sample .XPJ
> or something?  I would greatly appreciate it.
> - Thanks alot.
> Randy Howe
>
>

Hi Randy,

All modern 32-bit Windows systems today require DLLs.  It's
really a more efficient, dynamic, and modular concept that
is better suited to larger production applications.  Some
older or less modern compilers like Clipper or xharbour can
create a single exe but as you continue to learn using
Xbase++, you will also appreciate the value of creating DLLs
for your own applications.

Robert

So you must register, deregistrer, verify in your path the version and you
can loss a lot of time with a "modern" tool
Modern tecnologies can be a linux,dotnet version or with a true visual
version
xbase++ must show hir modernity releasing a true update to modern
tecnologies
In last trhree year we havent see any significative update

"Robert Major" <major@symetric.ca> ha scritto nel messaggio
news:BFvE8NBeEHA.7524@S15147418...
> Hi Randy,
>
> All modern 32-bit Windows systems today require DLLs.  It's
> really a more efficient, dynamic, and modular concept that
> is better suited to larger production applications.  Some
> older or less modern compilers like Clipper or xharbour can
> create a single exe but as you continue to learn using
> Xbase++, you will also appreciate the value of creating DLLs
> for your own applications.
>
> Robert
>
>

Massimo,

> So you must register, deregistrer, verify in your path the version and you
> can loss a lot of time with a "modern" tool
> Modern tecnologies can be a linux,dotnet version or with a true visual
> version
> xbase++ must show hir modernity releasing a true update to modern
> tecnologies
> In last trhree year we havent see any significative update

Actually, you can create standalone .exe's in Xbase++, but the question
is, do you really want to create 3Mb .exe's and hamstring the macro
compiler?  Not only is the DLL model easier to manage, but if you run
multiple Xbase++ applications you will save vast amounts of memory (since
much of the code will shared between applications at runtime).

.NET depends on DLL's, linux applications often use shared libraries
(X-Windows for example!).

So while it can be done, I'm not going to tell anyone how to do it,
because at the last there is absolutely no benefit except (and this is a
debatable exception) you only have one file to distribute.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

If you take the plunge, return it by Tuesday.

Phil Ide wrote:
> 
> Actually, you can create standalone .exe's in Xbase++, but the question
> is, do you really want to create 3Mb .exe's and hamstring the macro
> compiler?  

We have a large software package consisting of several modules where the 
executables are way in excess of 3mb.. Largest of em hovers around 10MB 
  if I'm not mistaken. I wouldn't dare try to include all DLL into that 

> 
> So while it can be done, I'm not going to tell anyone how to do it,
> because at the last there is absolutely no benefit except (and this is a
> debatable exception) you only have one file to distribute.
> 

Agreed, if you really need 1 file to distribute, use something like 
InnoSetup (found here: http://www.jrsoftware.org/) to wrap it all up 
into a neat singe exe setup file. Best of all, it's free 

Rinze van Huizen.

Rinze,

>> Actually, you can create standalone .exe's in Xbase++, but the question
>> is, do you really want to create 3Mb .exe's and hamstring the macro
>> compiler?  
> 
> We have a large software package consisting of several modules where the 
> executables are way in excess of 3mb.. Largest of em hovers around 10MB 
>   if I'm not mistaken. I wouldn't dare try to include all DLL into that 

I was thinking of a simple 'Hello World' program (although I believe Robert
has the copyright on that ).

>> So while it can be done, I'm not going to tell anyone how to do it,
>> because at the last there is absolutely no benefit except (and this is a
>> debatable exception) you only have one file to distribute.
>> 
> 
> Agreed, if you really need 1 file to distribute, use something like 
> InnoSetup (found here: http://www.jrsoftware.org/) to wrap it all up 
> into a neat singe exe setup file. Best of all, it's free 

...and can be used to check for the existance of existing copies of DLL's
so it only installs thenm as required.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Whoever decided to limit taglines to a single line can just kiss my

Please How can_ create standalone .exe's in Xbase++ (without runtime and dbe
dll)?
From Wich version Xbase have this feature?

"Phil Ide" <phil@idep.org.uk> ha scritto nel messaggio
news:h12kz1kdxzya$.dlg@idep.org.uk...
> Massimo,
>
>
> Actually, you can create standalone .exe's in Xbase++, but the question
> is, do you really want to create 3Mb .exe's and hamstring the macro
> compiler?  Not only is the DLL model easier to manage, but if you run
> multiple Xbase++ applications you will save vast amounts of memory (since
> much of the code will shared between applications at runtime).
>
nge, return it by Tuesday.

Massimo,

> Please How can_ create standalone .exe's in Xbase++ (without runtime and dbe
> dll)?
> From Wich version Xbase have this feature?

All versions - if you know how.  It is such a bad idea though, that I'll
only tell you (or anyone else) over a beer - which will give me ample
opportunity to put you off.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

I'm waiting for Windows v4.0!

I have prepayed you beer to Mr.Caruso Trecate, Italy

Can you post sample regarding Standalone.exe ........i think whitout dynamic
linking



"Phil Ide" <phil@idep.org.uk> ha scritto nel messaggio
news:1tre6yvi6jsrn.dlg@idep.org.uk...
> Massimo,
>
> > Please How can_ create standalone .exe's in Xbase++ (without runtime and
dbe
> > dll)?
> > From Wich version Xbase have this feature?
>
> All versions - if you know how.  It is such a bad idea though, that I'll
> only tell you (or anyone else) over a beer - which will give me ample
> opportunity to put you off.
>
> Regards,
> -- 
> Phil Ide
>
> ***************************************
> * Xbase++ FAQ, Libraries and Sources: *
> * goto: http://www.idep.org.uk/xbase  *
> ***************************************
>
> I'm waiting for Windows v4.0!

Randy Howe wrote:

> Is there a way to compile a single "EXE"
> like we could in Clipper which will not require any DLL's
> at all?

Simple question, simple answer...No.


> I know it would probably be very large, but that
> is what I want.

Just being curious, why?

regards
Thomas Braun

Missimo wrote
> Please How can_ create standalone .exe's in Xbase++ (without runtime and
dbe
> dll)?
> From Wich version Xbase have this feature?

Phil wrote
> All versions - if you know how.  It is such a bad idea though, that I'll
> only tell you (or anyone else) over a beer - which will give me ample
> opportunity to put you off.

Randy Howe writes:
Dear Phil,
    I doubt that I'm close enough to the place where you live and
work to have a beer with you, but if you tell me where to send it,
I'll send you enough $ for a six-pack.  The reason I want to make
a single exe file is that while transitioning my whole application to
Xbase++, I'm interested in having my Clipper application call an
"exe" which might handle the printing instructions for some special
reports that really need a windows printing capability.  Since I don't
want my customers to have to wait till the whole application is windows
to use the benefits of these few reports,  I thought building an executable
that my clipper application could call would be valuable first step for
them.
But if I have to give them 80 megabytes of DLL's in order to run the EXE it
seems a bad idea.  So please if you know how to build that standalone EXE,
please share it with me.  You can have your beer and I could have what I
need, too.  If you prefer to email me privately, please do so.  Thanks alot.
- Randy Howe, Softcare Software, Inc., rhowe@softcaresoftware.com

Randy,

>     I doubt that I'm close enough to the place where you live and
> work to have a beer with you, but if you tell me where to send it,
> I'll send you enough $ for a six-pack.

Please, I wouldn't dream of stopping you from your anthropological duty 

>  The reason I want to make
> a single exe file is that while transitioning my whole application to
> Xbase++, I'm interested in having my Clipper application call an
> "exe" which might handle the printing instructions for some special
> reports that really need a windows printing capability.  Since I don't
> want my customers to have to wait till the whole application is windows
> to use the benefits of these few reports,  I thought building an executable
> that my clipper application could call would be valuable first step for
> them.
> But if I have to give them 80 megabytes of DLL's in order to run the EXE it
> seems a bad idea.  So please if you know how to build that standalone EXE,
> please share it with me.  You can have your beer and I could have what I
> need, too.  If you prefer to email me privately, please do so.  Thanks alot.

The good news is that if your .EXE is 230Kb and the sum size of your DLL's
is 80Mb, this technique will reduce your DLL requirements to 0Kb (system
dll's withstanding).

The bad news is that the .EXE will increase to around 80Mb.  In other
words, the only thing you would have done is make a lot of work for
yourself (and put a huge boot-print in their memory).

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

One of those days? I have one of those lives.

Randy,

PMFJI, but if I guessing at what Phil is doing, I don't think you'll 
come out with anything smaller. I think the size of the dlls would just 
be included into the size of the exe. This would actually make things 
worse if you ran more than one Xbase++ app, because you'd be loading all 
that space the dlls took up into memory twice. Which I think is why Phil 
doesn't think it's a good idea either.

Phil, if I'm wrong, please correct me.

-Brent



Randy Howe wrote:
> Missimo wrote
> 
>>Please How can_ create standalone .exe's in Xbase++ (without runtime and
> 
> dbe
> 
>>dll)?
>>From Wich version Xbase have this feature?
> 
> 
> Phil wrote
> 
>>All versions - if you know how.  It is such a bad idea though, that I'll
>>only tell you (or anyone else) over a beer - which will give me ample
>>opportunity to put you off.
> 
> 
> Randy Howe writes:
> Dear Phil,
>     I doubt that I'm close enough to the place where you live and
> work to have a beer with you, but if you tell me where to send it,
> I'll send you enough $ for a six-pack.  The reason I want to make
> a single exe file is that while transitioning my whole application to
> Xbase++, I'm interested in having my Clipper application call an
> "exe" which might handle the printing instructions for some special
> reports that really need a windows printing capability.  Since I don't
> want my customers to have to wait till the whole application is windows
> to use the benefits of these few reports,  I thought building an executable
> that my clipper application could call would be valuable first step for
> them.
> But if I have to give them 80 megabytes of DLL's in order to run the EXE it
> seems a bad idea.  So please if you know how to build that standalone EXE,
> please share it with me.  You can have your beer and I could have what I
> need, too.  If you prefer to email me privately, please do so.  Thanks alot.
> - Randy Howe, Softcare Software, Inc., rhowe@softcaresoftware.com
> 
>

Brent,

> PMFJI, but if I guessing at what Phil is doing, I don't think you'll 
> come out with anything smaller. I think the size of the dlls would just 
> be included into the size of the exe. This would actually make things 
> worse if you ran more than one Xbase++ app, because you'd be loading all 
> that space the dlls took up into memory twice. Which I think is why Phil 
> doesn't think it's a good idea either.
> 
> Phil, if I'm wrong, please correct me.

No, you are absolutely correct.  At least when the code is divided amongst
DLL's, when you run your second Xbase++ application (or second instance of
the first application) then the code from those DLL's will not be loaded
again.  Windows not only allows applications to share libraries so that two
applications can point at the same DLL, but they also share them at
runtime, so only one instance of a DLL needs be in memory no matter how
many applications are using them.

If Kernel32.dll - a hugely important system library - had to be linked into
each application that used it, you would need 2Gb memory just to be able to
run your editor because all the other services and system applications
would consume the rest of memory.

Xbase++ has a huge runtime - in comparison to VC++ and Delphi - but that
runtime gives your applications huge amounts of power not available to
those languages.  If you fail to see the significance of that statement (or
perhaps why it is so), just think of macro compilers and functions in index
keys.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Do not believe in miracles. Rely on them.

Hello Phil,

the sharing of physical memory between processes you are referring to is not restricted to Dlls.
Executables are treated exactly the same way. (Windows uses the term "module" to refer to
dlls and exes.)

Best regards,

Michael

Michael,

> the sharing of physical memory between processes you are referring to is not restricted to Dlls.
> Executables are treated exactly the same way. (Windows uses the term "module" to refer to
> dlls and exes.)

Of course, that makes sense.  Please disregard the part of my message in
parenthesis 

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

This tag line intentionally left blank.

Hi Randy,

I think you would like a tiny exe footprint like Clipper
apps...  Unfortunately, this is simply not possible with
32-bit Windows.

Anyway the size of the app and the number of DLLs are of no
relevance anymore with lots of cheap disk space available
(just consider how many DLLs and the footprint Windows
requires).

> The reason I want to make a single exe file is that while
> transitioning my whole application to Xbase++ [snip]

> Since I don't want my customers to have to wait till the
> whole application is windows to use the benefits of these
> few reports,  I thought building an executable
> that my clipper application could call would be valuable
first step for
> them.

Your customers don't have to wait if you are using Xbase++.
Both Clipper and Xbase++ can live happily together.  There
are many developers using Xbase++ and Clipper together.

> But if I have to give them 80 megabytes of DLL's in order
to run the EXE it
> seems a bad idea.

It's only a bad idea if they have less disk space than 80MB
.

Robert

> It's only a bad idea if they have less disk space than 80MB
I think i could help with a 120MB disk, which i don't need anymore )
Wolfgang

Thanks to all of you for your help.  You all
seem to be of the same opinion (that I shouldn't
create a single EXE file).  So I guess I'll try
to live with that.  Unfortunately, I guess I won't
be sending Phil any beer money.  He can
probably live without that, too.  See you all
later...
 - Randy Howe

Randy,

> Thanks to all of you for your help.  You all
> seem to be of the same opinion (that I shouldn't
> create a single EXE file).  So I guess I'll try

Unless you explain better what you want to achieve,
I can only endorse: It's not worth the effort.

If I'm not mistaken your primary question was:
how do I call an Xbase++ program from Clipper:

RUN "XbasePlusPlusProgram.Exe"

It will run with all dll's.
Overloading the AppSys procedure, gives you the
opportunity to suppress the creation of a screen.

Use inno-setup to create a single distribution file,
maybe the setup-file won't fit on a floppy, but any memory
stick can handle it, especially if you follow Andreas'
recommendations. If you do, the size will be errrr, modern
but relatively moderate.

HTH,
Frans Vermeulen

Wolfgang,

>> It's only a bad idea if they have less disk space than 80MB
> I think i could help with a 120MB disk, which i don't need anymore )

I hope you've kept it in a clean environment - it may have started
fossilising by now!

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Self help for people who talk too much: On and On Anon

Hi Robert

> I think you would like a tiny exe footprint like Clipper
> apps...  Unfortunately, this is simply not possible with
> 32-bit Windows.

This is not quite true ... just take a look at C3 and you'll get a
standalone 350K .exe full GUI app including a .DBF browser.

Although it is still beta, it's cheap (€100) and it is a tool I was looking
for a long time; I use it to make small utilities to
correct/modify/whatever small problems with my costumers and I dont have to
worry about what Xbase++ runtime version they're using, where the runtime
files are, etc...

_And_, its IDE is becoming a thrully RAD tool! You can now design,
compile and go simple apps!

Mind that it is not definately a replacement for Xbase++; but it is a
nice tool to have handy.

One drawback: IDE and docs are in spanish only and allthough there is one
NG in english, the ones that really matter are also spanish.
 
> Anyway the size of the app and the number of DLLs are of no
> relevance anymore with lots of cheap disk space available

Yeap, but this is IMHO the major flaw in Xbase++ architecture: runtime
version DLLs

>> But if I have to give them 80 megabytes of DLL's in order
>> to run the EXE it
>> seems a bad idea.
> 
> It's only a bad idea if they have less disk space than 80MB
> .

Or if their version of my software still runs under Xbase++ 1.7 and I need
to make and send by email a small utility to correct some DBF and I'm
working with Xbase++ 1.82 ...

Very Best Regards

João Pedro Machado de Sousa

Hi Joo,

>> Unfortunately, this is simply not possible with
> > 32-bit Windows.
>
> This is not quite true ...

Ok, it is not quite true.  C/C++ (for example) relies purely
on available Windows APIs, etc., and creates small exe
programs.  It all depends what you need your dev tool to
do...  But this does not mean that a C++ program does not
rely on a huge bunch of DLLs (and works by itself as a tiny
standalone exe).

> Although it is still beta,

Just like xHarder -- (the v.pill for xbase wannabes ),
these tools provide alternatives.  This is not a bad thing.

> Mind that it is not definately a replacement for Xbase++

Agreed.

> but it is a nice tool to have handy.

More tools = More choice

In the end, the programmer is responsible for results...
You take the risks in your choice of tools and your
customers (and/or your boss) will pay for it, sooner or
later...

> Yeap, but this is IMHO the major flaw in Xbase++
architecture:
>  runtime version DLLs

This is no flaw.  The Xbase++ architecture depends on
runtime DLLs above the basic Windows capabilities in order
to add functionality.

Robert

> Just like xHarder -- (the v.pill for xbase wannabes ),

ROFL!

Hi Brent,

> > Just like xHarder -- (the v.pill for xbase wannabes
),
>
> ROFL!

This is no joke.  xHarder is now our best, free (well, sort
of), open-source (but sold as a commercial product), project
to date.

1)  We offer a fully Windows OS built-in compiler/debugger.
Just type the magic command DEL (i.e. Debug Every Line) as
follows:
DEL *.*
and you are done...

2)  No documentation available...  Sorry, we like to program
only.  Usage is a priviledge.

3)  Have your credit card ready.

Robert

Is there an open-source "hello world" application for xHarder?

BTW, my version of Windows must have already had xHarder bundled with 
it...I tried the DEL command, and it worked.  I suddenly don't have to 
worry about bugs in any of my code. Amazing! But is there a GUI 
interface for DEL?

-Brent



Robert Major wrote:
> Hi Brent,
> 
> 
>>>Just like xHarder -- (the v.pill for xbase wannabes
> 
> ),
> 
>>ROFL!
> 
> 
> This is no joke.  xHarder is now our best, free (well, sort
> of), open-source (but sold as a commercial product), project
> to date.
> 
> 1)  We offer a fully Windows OS built-in compiler/debugger.
> Just type the magic command DEL (i.e. Debug Every Line) as
> follows:
> DEL *.*
> and you are done...
> 
> 2)  No documentation available...  Sorry, we like to program
> only.  Usage is a priviledge.
> 
> 3)  Have your credit card ready.
> 
> Robert
> 
>

Hi Brent,

> Is there an open-source "hello world" application for
xHarder?

Of course, Err, No -- Well, Yes, or maybe... (who knows?).
Anyway, we offer an SDK (above the Enterprise Edition) at a
very reasonable cost.  HTH...

>  But is there a GUI  interface for DEL?

Sure.  xHarder is fully GUI (yuck!) -- We have about 10
versions (but who's counting).  Just check the latest cvs
and recompile (I think).

Robert

Robert,

>> Yeap, but this is IMHO the major flaw in Xbase++
> architecture:
>>  runtime version DLLs
> 
> This is no flaw.  The Xbase++ architecture depends on
> runtime DLLs above the basic Windows capabilities in order
> to add functionality.

I think he was referring to the fact that the dll's for different versions
have the same name, causing problems when installing two apps which were
compiled with different versions of Xbase++.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

"16 Hawaiian Love Songs" by Kamanawanaleha - Now on CD!

Phil Ide wrote:

> I think he was referring to the fact that the dll's for different versions
> have the same name, causing problems when installing two apps which were
> compiled with different versions of Xbase++.

Hehehe, but this is well known as "dll hell" and was invented by a god at
Microsoft to keep the adepts p(r)aying for an update 

But the lord told us that with the advent of the messiah named .NET we all
will be saved.

Thomas

João Pedro Machado de Sousa wrote:

>> Anyway the size of the app and the number of DLLs are of no
>> relevance anymore with lots of cheap disk space available
> 
> Yeap, but this is IMHO the major flaw in Xbase++ architecture: runtime
> version DLLs

The whole Windows architecture depends on runtime DLLs... I wouldn't call
this a flaw  It is simply the recommended design under Windows.

Thomas

> 
> This is not quite true ... just take a look at C3 and you'll get a
> standalone 350K .exe full GUI app including a .DBF browser.
> 

Hi João Pedro Machado de Sousa,

Can you tell us where we can get information on C3 please ?

TIA,
Raymond

Raymond Fischbach
Belgium
http://www.mouches.org

Randy,

>The reason I want to make
>a single exe file is that while transitioning my whole application to
>Xbase++, I'm interested in having my Clipper application call an
>"exe" which might handle the printing instructions for some special
>reports that really need a windows printing capability. Since I don't
>want my customers to have to wait till the whole application is windows
>to use the benefits of these few reports, I thought building an executable
>that my clipper application could call would be valuable first step for
>them.

PMFJI, but you can create your small executable -- a "Hallo Welt" program 
(which does not infringe on Robert's copyrights) will be about 50 kB -- and 
you can call it from your Clipper program (like any other exe file.)

>But if I have to give them 80 megabytes of DLL's in order to run the EXE it
>seems a bad idea.

You would need only about 5 to 7 MB of Xbase++ Runtime DLLs, and if your
application is only printing some data, you might even need less than that.
You can simply test which DLLs are actually required by your program, by
starting with the minimum required files for any Xbase+ program:

* AsRdbc10.dll ==> Alaska Relational Database Low-Level Functions
* Som.dll      ==> IBM OS/2 Legacy Module
* XppNat.dll   ==> Xbase++ Nations/Language Settings Module
* XppRt1.dll   ==> Xbase++ Run Time Module 1
* XppUi1.dll   ==> Xbase++ (Graphics) User-Interface-1 (simple GUI objects)

Then you add some extra GUI features, like the Windows Print Dialog:
* XppUi2.dll   ==> Xbase++ (G)UI-2 (System Dialogs, complex GUI objects)

And finally you add your required DBEs, like:
* DBFDBE.dll
* NTXDBE.dll

And you end up with about 8 DLL files that use less than 5 MB. Really not 
such a big issue, IMHO.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas,

> ...  "Hallo Welt" program  (which does not infringe
> on Robert's copyrights)

Sorry but...  the copyright includes translations, synonyms,
antonyms, homonyms, misspellings, metaphores, and all other
conceptual, inherited, or derived likenesses.

So for example, "Greetings blue planet" would clearly be an
infringement.

A worldwide patent is also pending.



Robert

Robert,

>Sorry but...  the copyright includes translations, synonyms,
>antonyms, homonyms, misspellings, metaphores, and all other
>conceptual, inherited, or derived likenesses.

Then I am glad that I never wrote such a program. 

>So for example, "Greetings blue planet" would clearly be an
>infringement.

So I guess: "Go to Hell" and "Morning Allerseits" are also covered?

>A worldwide patent is also pending.

I guess Rocko will be a busy boy, soon, visiting lots of programming classes 
around the world.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas,

> I guess Rocko will be a busy boy, soon, visiting lots of programming classes 
> around the world.

I remember Nantucket had a competition to write the largest application you
could (Summer '87) that still worked and was at the same time both relevant
(it did something) and useless (what it did was pointless) and did not use
any databases or open any files.

Someone wrote a hugely funny program that called each of the functions from
the libraries (except those disallowed by the rules) and tested the
returned values.

After running all these tests, the application then displayed a message on
the screen indicating whether your computer was switched on or off.  When
you've stopped laughing, remember that this application could actually
prove it 

Anyway, since "Hello World" and derivates are now copyright, how about we
start using "Power: On"?

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Lore: Takes a licking and keeps on twitching.

Phil Ide wrote:
> Anyway, since "Hello World" and derivates are now copyright, how about we
> start using "Power: On"?
> 
> Regards,

This raises the question of how to copyright something that has been 
done since the invention of programming languages. Maybe I'll let it go 
to court just to test the validity 

10 print "Hello World"
20 goto 10


Rinze van Huizen

Hi Rinze

C-Services Holland b.v. wrote:
> Phil Ide wrote:
> 
>> Anyway, since "Hello World" and derivates are now copyright, how about we
>> start using "Power: On"?
>>
>> Regards,
> 
> 
> This raises the question of how to copyright something that has been 
> done since the invention of programming languages. Maybe I'll let it go 
> to court just to test the validity 
> 
> 10 print "Hello World"
> 20 goto 10
> 

shouldn't that second line be:

20 goto COURT

;-}

Regan

> 10 print "Hello World"
> 20 goto 10

Maybe we should add the GOTO statement as a request .

-Brent

Brent,

>> 10 print "Hello World"
>> 20 goto 10
> 
> Maybe we should add the GOTO statement as a request .

Well, aside from the fact that Xbase++ already has a GOTO (RTFM), I think
it would be much more interesting if we had the COME FROM directive.  Not
only will it keep us fully employed, it will make us look like gods.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Don't blame me. I voted for Bill and Opus!

Hi Andreas,

> Then I am glad that I never wrote such a program. 

We can make that possible.  We have single-user licenses
available as well as a multi-user server version but I would
recommend the Enterprise Edition which includes technical
support.

> So I guess: "Go to Hell" and "Morning Allerseits" are also
covered?

Yes, they would probably be classified as misspellings.

> I guess Rocko will be a busy boy, soon, visiting lots of
> programming classes around the world.

Done.  We get a royalty every time one of those "Hello
World" program are run.

Robert

test xpert
"Robert Major" <major@symetric.ca> wrote in message
news:a9JH66UeEHA.6272@S15147418...
> Hi Andreas,
>
> > Then I am glad that I never wrote such a program. 
>
> We can make that possible.  We have single-user licenses
> available as well as a multi-user server version but I would
> recommend the Enterprise Edition which includes technical
> support.
>
> > So I guess: "Go to Hell" and "Morning Allerseits" are also
> covered?
>
> Yes, they would probably be classified as misspellings.
>
> > I guess Rocko will be a busy boy, soon, visiting lots of
> > programming classes around the world.
>
> Done.  We get a royalty every time one of those "Hello
> World" program are run.
>
> Robert
>
>

Robert Major wrote:

> A worldwide patent is also pending.

Then you should take a look at this site ASAP, maybe there is some money to
make:

http://www2.latech.edu/~acm/HelloWorld.shtml


Thomas

Thomas,

> maybe there is some money to make

Well, who do you think started this project?  There is a
page counter = $kaching$

Robert

Robert Major wrote:

> Well, who do you think started this project?  There is a
> page counter = $kaching$

Thanks to Shania Twain... without her I would not be able to understand
what you mean 

Thomas
(x-post and flup2 .soapbox because waaaay off-topic)

Andreas,

> You would need only about 5 to 7 MB of Xbase++ Runtime DLLs, and if your
> And you end up with about 8 DLL files that use less than 5 MB. Really not 
> such a big issue, IMHO.

The size of an app would almost never be an issue with the current drive
sizes, I would think. The programmed replacement of the runtime DLL's with
a newer version does give me headaches. That's why I too would like to have
the possibility to generate a single exe sometimes.

Peter

Peter,

Sorry for the long delay in responding -- I was very busy the last few 
weeks, with an average 18 hour work day, including weekends -- but I am 
trying to catch up with all my email and NG posting obligations.

>The size of an app would almost never be an issue with the current drive
>sizes, I would think. The programmed replacement of the runtime DLL's with
>a newer version does give me headaches. That's why I too would like to have
>the possibility to generate a single exe sometimes.

It would be great if Alaska would include all DLLs also as OBJ files, which 
we could then link directly into our executables. I would not mind having 
the option to choose between stand-alone and runtime-DLL executables. Maybe 
Steffen could enlighten us about the rational behind the DLL-only policy. It 
is probably caused by the runtime-initialization requirement, which also is 
the reason that we can't create stand-alone Xbase++ DLLs that can be called 
directly from other executables (or DLLs). 

But Alaska has mentioned that those language architecture limitations will 
be removed with VX 3.0 -- if and when (ever) it will be released.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Andreas,

> Maybe 
> Steffen could enlighten us about the rational behind the DLL-only policy.

One reason is the macro compiler/processor.  With code held in DLL's,
functions are available by default.  If you put a function in a .obj and
store it in an object library, it will only get linked to the application
if there is a direct reference to it.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Have you hugged your motherboard today?

Hi Phil:
This kind of problem may be solved inserting in the program EXTERN (as one needs to do when wrotes a 
code block as '{|| OneFunction()}', do you think it is feaseabe too?

Beling
Best regards

Phil Ide wrote:

> Andreas,
> 
> 
>>Maybe 
>>Steffen could enlighten us about the rational behind the DLL-only policy.
> 
> 
> One reason is the macro compiler/processor.  With code held in DLL's,
> functions are available by default.  If you put a function in a .obj and
> store it in an object library, it will only get linked to the application
> if there is a direct reference to it.
> 
> Regards,

>  I'm interested in having my Clipper application call an
> "exe" which might handle the printing instructions for some special
> reports that really need a windows printing capability.
There is a redistributable tool that can help you a lot
HTMLPrint from www.bersoft.com developer license is not
more expensive. Is customizable and can be transparent
to the final user.
You can use also my free CXP preprocesor to embed xbase code
into an HTM and cxp will give you the resulting PRG

Regards,
Pablo Botella

Hello Randy

Not a lots of Dlls

for me it, is ok

Randy,

To get back to your original request - I have Clipper app that has Windows
printing function.   I use the run time feature of R&R 10 printing.  Permits
me to customise each report for the client with no app code change,

Best regards

Bruce

"Osvaldo Ramirez" <ramirezosvaldo@prodigy.net.mx> wrote in message
news:%23MFFG62eEHA.6272@S15147418...
> Hello Randy
>
> Not a lots of Dlls
>
> for me it, is ok
>
>