1. RE: Suggestion for 2.3
You know, Chris,
I think Robert likes the fact that his installation program is written
in his own language and works in both DOS and Windows. Those of us
familiar with any particular Windows-based installation program are
probably more than welcome to submit a standalone installation program
that does what the typical point-and-clicker expects. However, I do
realize your point; why not use tools already available to us? Didn't
somebody already write such a tool using Euphoria?
I thought about how cool it would be to do a complete 'Euphoria for
Windows' install package which would do a complete PD install of
Euphoria with the latest release of Win32Lib and Judith's latest Editor
and maybe some other related stuff...
Errr... still sounds like a neat idea but that person would need to get
permissions from authors of all resources involved and that could be a
pain in the ...
Anybody interested? Am I volunteering or is there an eager young soul
out there with more experience and time?
Just my thoughts,
-- Brian
Chris Bensler wrote:
> If you haven't thought about it already,
> you should add support for setting up windows associations to the
> install program for EU
>
> sure, there are files in the archives for helping you to do this, but
> they are more complicated than just doing yourself by hand..
>
> Maybe you should consider adding a windows based installation wizard.
> I know, it will make the distribution bigger, but it could be optional.
> I think most people would opt for it anyways..
>
> Chris
2. RE: Suggestion for 2.3
Howdy!
> Seeing as you've volunteered Brian :).. I would recommend doing the
>installer in a component style, so users could choose which components
>they want to DL and install with their EU package. It could also allow
>for future installation/upgrades of the various components..
>You could even make it check for updated versions of the different
>components, via the web, that they installed, and prompt for upgrading..
>This would be a little tricky, and I myself have never been too keen on
>update wizards, but some people like, and it definitely has it's
>advantages..
>Could also be optional..
Another thing to consider is that while an "upgrade" option is fine and
dandy, the writer of the installation app should really make sure that the
components of the install app stay at the most current level. For the core
Euphoria files themselves, this would not be a hard thing to do. But it
might get a bit tedious where win32lib.ew and Judith's IDE is concerned, as
these are developing programs, and new releases come out for both of them
every couple of months or so. Since those two projects will probably
*never* release at the same time, the install app writer will ideally need
to re-create and re-release the installation app every time *one* of them
is updated.
Just something for Mr. Broker to consider whilst chewing on his foot. 
-- Travis --
3. RE: Suggestion for 2.3
Chris Bensler wrote:
> Except for a TSR.
>
> of course that would mean that the authors of the various components
> would have to keep the same file names and locations for the new
> releases..
TSR?!?! What are you talking about? There are no TSRs in Windows...just
have a Euphoria update program in the system tray waiting for an
internet connection just like ICQ.
4. RE: Suggestion for 2.3
On 30 Apr 2001, at 14:42, sephiroth _ wrote:
>
>
> Chris Bensler wrote:
> > Except for a TSR.
> >
> > of course that would mean that the authors of the various components
> > would have to keep the same file names and locations for the new
> > releases..
>
> TSR?!?! What are you talking about? There are no TSRs in Windows...just
> have a Euphoria update program in the system tray waiting for an
> internet connection just like ICQ.
TSR = terminate and stay resident, right? But you can have tsrs in windoze,
load them as DEVICE= lines, and they work fine. I used a dos tsr i wrote in
Turbo Pascal, for dos5, win3.1, 3.11, WfW, and the first year of win95. It was
a reconfigureable-while-running ramdrive.
Writing them in Eu is another matter tho. Here's a thought, write the tsr body
in Eu, translate it to C, then inline the compiled C in a shell of a language
that will let you write a dos tsr? errrr, nevermind.
Kat
5. RE: Suggestion for 2.3
On 30 Apr 2001, at 7:03, Travis Beaty wrote:
>
> Howdy!
>
>
> > Seeing as you've volunteered Brian :).. I would recommend doing the
> >installer in a component style, so users could choose which components
> >they want to DL and install with their EU package. It could also allow
> >for future installation/upgrades of the various components..
> >You could even make it check for updated versions of the different
> >components, via the web, that they installed, and prompt for upgrading..
> >This would be a little tricky, and I myself have never been too keen on
> >update wizards, but some people like, and it definitely has it's
> >advantages..
> >Could also be optional..
>
> Another thing to consider is that while an "upgrade" option is fine and
> dandy, the writer of the installation app should really make sure that the
> components of the install app stay at the most current level. For the core
> Euphoria files themselves, this would not be a hard thing to do. But it might
> get a bit tedious where win32lib.ew and Judith's IDE is concerned, as these
> are
> developing programs, and new releases come out for both of them every couple
> of
> months or so. Since those two projects will probably *never* release at the
> same time, the install app writer will ideally need to re-create and
> re-release
> the installation app every time *one* of them is updated.
>
> Just something for Mr. Broker to consider whilst chewing on his foot.
Another thing to consider is what to do with the new files. Overwrite the old
files, possibly installing new bugs and breaking old code, without telling the
user? Install to a new directory? Move the old out to an /unused dir and drop
the new files in,, where? I prolly have 10 win32lib's laying around, of
different
versions, because some programs work with one version and not another.
Automatically downloading a new win32lib wouldn't be any help to me, but
knowing a new one was posted might be. Same for other contributions.
Actually getting the programs from RDS isn't a problem, automatically
unzipping them and what to do with them after that is the problem.
Kat
6. RE: Suggestion for 2.3
the problem with writing a _DOS_ TSR in Euphoria is that Eu is
intepreted. if you want to write a TSR, you do something like hook int
0x1c to your code. but since Eu is interpreted, there's nothing to hook
TO, except maybe, a chunk of the interpreter.
7. RE: Suggestion for 2.3
On 30 Apr 2001, at 16:51, sephiroth _ wrote:
> the problem with writing a _DOS_ TSR in Euphoria is that Eu is
> intepreted. if you want to write a TSR, you do something like hook int
> 0x1c to your code. but since Eu is interpreted, there's nothing to hook
> TO, except maybe, a chunk of the interpreter.
Unless you translate it to C and then compile it. Surely you can find a dos C
compiler that you can drop the translated code into?
Kat
8. RE: Suggestion for 2.3
Kat wrote:
> Unless you translate it to C and then compile it. Surely you can find a
> dos C
> compiler that you can drop the translated code into?
you probably could, but not many C compilers can make TSR's from source
code. here's what making a TSR involves:
1. write some code and hook it to int 0x1c or 0x8(for being called
regularly), 0x9(for being called on every keypress), or 0x28(for being
called when DOS is idle)
2. make that code CAPABLE OF RESTORING ALL REGISTERS. any destroyed
registers could mean disaster
so you can't simply write some C code on the fly and hook it to an
interrupt. it has to be specially coded. also, it must be coded in the
tiny model to make it work properly, and you'll need a C compiler
capable of inserting assembly so you could insert a pusha at the
beginning and a popa at the end
9. RE: Suggestion for 2.3
On 30 Apr 2001, at 18:02, sephiroth _ wrote:
>
>
> Kat wrote:
> > Unless you translate it to C and then compile it. Surely you can find a
> > dos C
> > compiler that you can drop the translated code into?
>
> you probably could, but not many C compilers can make TSR's from source
> code. here's what making a TSR involves:
>
> 1. write some code and hook it to int 0x1c or 0x8(for being called
> regularly), 0x9(for being called on every keypress), or 0x28(for being
> called when DOS is idle)
> 2. make that code CAPABLE OF RESTORING ALL REGISTERS. any destroyed
> registers could mean disaster
>
> so you can't simply write some C code on the fly and hook it to an
> interrupt. it has to be specially coded. also, it must be coded in the
> tiny model to make it work properly, and you'll need a C compiler
> capable of inserting assembly so you could insert a pusha at the
> beginning and a popa at the end
Well, like i said, i did it in Turbo Pascal, and didn't do tiny model, and i
didn't
hook those ints you listed. And even tho it was a device driver, i didn't put it
in the device driver chain, that's how i make it re-configureable *while it was
running*.
Kat
10. RE: Suggestion for 2.3
> -----Original Message-----
> From: sephiroth _ [mailto:euman2376 at yahoo.com]
I'm not familiar with DOS interrupts, but...
> 2. make that code CAPABLE OF RESTORING ALL REGISTERS. any destroyed
> registers could mean disaster
I believe that all compilers should do this. AFAIK, it's a requirement that
any called procedure leave the registers as they found them (the exception
being EAX, which is used to return a value)--unless maybe you're using
Watcom with the fastcall calling convention (args passed in registers).
Anything you're calling in exw/exu (can't use c_func stuff in ex, although
if you can get the pointer to the procedure you can call it through asm) has
to be stdcall, although it shouldn't be too difficult to call cdecl, and
fastcall is probably doable, too.
Matt Lewis
11. RE: Suggestion for 2.3
Whoah...
I certainly wasn't thinking of something *that* involved. I will
probably experiment with simpler ideas and let everybody know how it
goes...
-- Brian
sephiroth _ wrote:
>
> Kat wrote:
> > Unless you translate it to C and then compile it. Surely you can find a
> > dos C
> > compiler that you can drop the translated code into?
>
> you probably could, but not many C compilers can make TSR's from source
> code. here's what making a TSR involves:
>
> 1. write some code and hook it to int 0x1c or 0x8(for being called
> regularly), 0x9(for being called on every keypress), or 0x28(for being
> called when DOS is idle)
> 2. make that code CAPABLE OF RESTORING ALL REGISTERS. any destroyed
> registers could mean disaster
>
> so you can't simply write some C code on the fly and hook it to an
> interrupt. it has to be specially coded. also, it must be coded in the
> tiny model to make it work properly, and you'll need a C compiler
> capable of inserting assembly so you could insert a pusha at the
> beginning and a popa at the end
>
>
