1. mac.exe
- Posted by Noah Smith <nhs6080 at UNIX.TAMU.EDU> Sep 21, 1998
- 595 views
Ummmm.... My brother, well, he's a Mac guy. And he really thinks Euphoria is neat. What is the likelihood of ex.exe or exw.exe running under an emulator? Or, contrarily, how hard would it be to port it to something like "mac.exe" or is that totally wacko? snortboy
2. Re: mac.exe
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Sep 21, 1998
- 568 views
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDE5B0.195320C8 charset="iso-8859-1" Noah Smith wrote: > how hard would it be to port it to something like "mac.exe" > or is that totally wacko? Most of the C programs written for the PC assume that a memory address remains fixed. But that's not the way it works on the Mac. Instead of using memory pointers, the Mac uses memory handles. You get an address that points to and address holding your memory address - a double indirection. That's because the Mac handles memory, and does heap compaction from time to time. As a result, porting C programs from the PC to the Mac can be less than trivial, especially if they rely heavily on pointers - and Euphoria and Pete's Euphoria clone fall into that category. I had hoped to write a Euphoria clone to run on the Mac, but abandoned the project. If the Euphoria interpreter spit out bytecodes (or Java bytecodes), portability would be much simpler. -- David Cuny ------_=_NextPart_001_01BDE5B0.195320C8 charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2232.0"> <TITLE>RE: mac.exe</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Noah Smith wrote:</FONT> </P> <P><FONT SIZE=3D2>> how hard would it be to port it to something = like "mac.exe" </FONT> <BR><FONT SIZE=3D2>> or is that totally wacko?</FONT> </P> <P><FONT SIZE=3D2>Most of the C programs written for the PC assume that = a memory address remains fixed. But that's not the way it works on the = Mac.</FONT></P> <P><FONT SIZE=3D2>Instead of using memory pointers, the Mac uses memory = handles. You get an address that points to and address holding your = memory address - a double indirection. That's because the Mac handles = memory, and does heap compaction from time to time.</FONT></P> <P><FONT SIZE=3D2>As a result, porting C programs from the PC to the = Mac can be less than trivial, especially if they rely heavily on = pointers - and Euphoria and Pete's Euphoria clone fall into that = category.</FONT></P> <P><FONT SIZE=3D2>I had hoped to write a Euphoria clone to run on the = Mac, but abandoned the project. If the Euphoria interpreter spit out = bytecodes (or Java bytecodes), portability would be much = simpler.</FONT></P> <P><FONT SIZE=3D2>-- David Cuny</FONT> </P> </HTML> ------_=_NextPart_001_01BDE5B0.195320C8--
3. Re: mac.exe
- Posted by Hawke <mdeland at NWINFO.NET> Sep 22, 1998
- 581 views
snortboy: >What is the likelihood of ex.exe or exw.exe running >under an emulator? theory says that if it's a *good* emulator, that it will function as an emulator and emulate what it's supposed to be emulating. ;) what that means to me is, the likelihood _should_ be high with a good emulator, and low with a bad one. >Or, contrarily, how hard would it be to port it to >something like "mac.exe" or is that totally wacko? >Cuny, David wrote: >As a result, porting C programs from the PC to >the Mac can be less than trivial, especially if >they rely heavily on pointers - and Euphoria and >Pete's Euphoria clone fall into that category. okay, in this arena i know enough to be only dangerous, but perhaps not correct. my recollection of ANSI C intention/definition is such that, if you write a program that is truly ANSI C and then recompiled that program on another platform, it should work, no? now of course, with all it's extreme optimization, Euphoria wouldn't recompile cross-platform, and PEU may not by now. but, what if, PEU was taken back to a stage that was ANSIc and we began there? >If the Euphoria interpreter spit out bytecodes >(or Java bytecodes), allright... the way i understand bytecodes actual "function"... ergo: how it does what it does... every reserved word has a "universal" identifier and after that point, each variable gets it's own moniker. then an interpreter that understands this universal language, reads these codes and executes them in a linear fashion. what we then need are 3 things: 1>interpreters (run time executors) for all platforms that understand "universal" 2>translators for all platforms that take .e and .ex files and spit out "universal" 3>the actual definition of "universal" not necessarily in this order :> #3 doesnt seem so bad... especially with EU... it gets a little gnarly tho, because of the following: the byte is a universally understood storage medium. but a byte can only hold 256 individual values, meaning no more than 256 reserved words and variables *combined*. myself, i can use 256 variables alone, in a real big hurry, not counting reserved words... allright you say, lets use int. everyone has int, right? well, int varies like *alot* not just between platforms, but sometimes within platform as well. EU has enormous int, but pascal is like -32K..32K (or -64..64 is it?)... either way... pascal's is much much smaller... well this descrepancy wouldn't be tolerable for this type of affair. we're left then with what i believe java prolly does.. char... actually dual char i think... sets of pairs of characters representing reserved words. well that's good you say, but what about our precious variables, and data, and constants, and strings and the like? unless i'm mistaken again, we cheat. one of the reserved word 'tokens' tells the translator(run time) that what is to follow (and for how long) will be a value, or a variable name, or a constant... one token for each of these (and other) possibilites. when you look at it from this standpoint, be my understanding actually right or wrong of how "java" (or any other bytecode language) does it, it begins not to look quite so daunting. another thing that looking at it this way reveals, especially with euphoria, is that 256 reserved words might actually work out to be "alot"... at this point i think i should pointout & clarify "reserved word" here... that would be all EU builtin func/proc names, as well as all the math/boolean/sequence operators. we can leave the operators as they sit, no need to translate them as they already have a value from 0-255...cool... life made easy already... now we simply give the reserved "words" a value from the ones left over, and we'll need to reserve a couple more for helping to define variables/values/constants. let's suppose we pick 12 as the number for "sequence". we need another number to represent "how many of the following bytes are to be used as the name of this variable" or, hrmmm... for that matter, whitespace can be real damned handy here as i think about it. not to mention the {} and the ','. something like: sequence abcd {m,a,r,y, ,h,a,d, ,a, ,l,i,t,t,l,e} could be turned into 'universal' rather easily in the translator parser. 12 65 66 67 68 (and then the { would let the parser know that the data was coming... you get the idea) here's the neat part... reverse translators... since euph (DOS) already understand .e and .ex then we need only to reverse the algorithm for the DOS mode translator to take a set of bytecode/tokens and make ex.exe run this newly generated .ex file. I see this as being potentially handy, and perhaps powerfull indeed. especially for the web... streaming euphoria? you could make web pages that -executed- just like activeX and java pages do... how would this work? okay, lets say we start with saying that from now on, .exb is the extension for Euphoria eXecutable Bytecode. we then need exb.exe which is the ex.exe bound with a bytecode (universal) interpretive front end. the plugin would also be exb.exe. someone downloads that, and associates *.exb with exb.exe and whenever they click on a link that is like www.poot.com/game.exb netscape is already smart enough to search for filetype associations and spawn the proper program. viola! getting excited yet? i don't think it would be that hard to make a DOS translator from universal->.ex and .ex->universal?!?!? would it??? </endLengthyReply> sowwy, got longwinded... --Hawke'
4. Re: mac.exe
- Posted by David Cuny <dcuny at LANSET.COM> Sep 22, 1998
- 609 views
Hawke wrote: >okay, in this arena i know enough to be only dangerous, >but perhaps not correct. my recollection of ANSI C >intention/definition is such that, if you write >a program that is truly ANSI C and then recompiled >that program on another platform, it should work, no? In the case of memory allocation, the answer is no. >now of course, with all it's extreme optimization, >Euphoria wouldn't recompile cross-platform, and >PEU may not by now. but, what if, PEU was taken >back to a stage that was ANSIc and we began there? We're not talking about extreme optimization here, but the basic mechanism used to implement sequences (pointers) and opcodes (function pointers). If you got rid of that part, all you would have left would be an interpreter. >>If the Euphoria interpreter spit out bytecodes >i don't think it would be that hard to make a DOS translator >from universal->.ex and .ex->universal?!?!? would it??? It would definitely be feasible to write a bytecode translator. I've been playing around with that approach. But it's harder than is sounds, because you still have to implement the sequence engine and bytecode interpreter to deal with the Mac's quirky memory management scheme. Generating a Java .class file is another option. Writing a sequence engine is the hardest part, although I think that sequences can be roughly be mapped to arrays. The main appeal of this approach is that Java is already ported to lots of different machines. If you were really gung-ho, you could generate a .java file (Java bytecodes) directly... -- David Cuny
5. Re: mac.exe
- Posted by Hawke <mdeland at NWINFO.NET> Sep 22, 1998
- 589 views
------------------------------------------------------------- side note: new keyword--UniEU=Universal Euphoria pronounced-- "you-nee-you" Euphoria bytecode definitions -------------------------------------------------------- David Cuny wrote: > Hawke wrote: >>if you write >>a program that is truly ANSI C and then recompiled >>that program on another platform, it should work, no? > In the case of memory allocation, the answer is no. ok, my C is real rusty (i hope to keep it that way:) but my understanding is that getmem() and free() were routines written such that when you compiled on another platform, the functions were written differently internally to grab/release memory without you having to worry about things like we're discussing. i'm almost *certain* that as i was at univ, learning how to know enuff to be dangerous, that i routinely wrote programs that i would compile depending upon my current physical location. if it was noon lunch, i'd be in a lab, floppy in hand, working on a specific program and using a linux box. if it was bout 5pm, i'd be in the mainframe room, working (ie:income), and also doing 'homework' (namely said program) and using the VAX (ALPHA processor) C compiler, on the same program, and i would then go home and (still same floppy, the vax & linuxbox could read dos floppies) work on that program on my PC djgpp compiler... complete crossplatform compiling, and i used get/free rather often, and of course a couple different make files had to be made at the beginning... so, i'm not sure about what your answer here means... clarify? >>now of course, with all it's extreme optimization, >>Euphoria wouldn't recompile cross-platform >We're not talking about extreme optimization here, but the >basic mechanism used to implement sequences (pointers) and >opcodes (function pointers). well.... *ponder*... not sure about this, but isn't there a generic pointer type inherent to ALL c? *pThis is *pThis is *pThis no matter what compiler u use... it's the compilers job to take the platform specific issues *away* from the coder, by rewriting it's libraries for each platform. (or was that ^pThis... hrm, get my c and pascal confus-el-ed sumtimes) lastly, i'd swear i heard a professor tell me that the reason pointers were created was because they were to be used by programmers needing platform*independence*. that no matter what platform you were using, you were simply getting a variable that automatically held a valid memory address of a particular variable/constant/value you wanted to 'point' to. you declare a pointer by declaring the type of data that the variable your going to point to is holding. you don't declare it as a variable that's going to hold a memory address ("well do I need a word,DBLword,64bit,128bit etc" NOT!), the compiler does that part for you. am i wrong about this? >it's harder than is sounds, because you still have to >implement the sequence engine and bytecode interpreter to >deal with the Mac's quirky memory management scheme. all right, given, you have to do funky, platform specific wildchildrodehard things to get sequences to run (i mean truly *run* like EU, not canter or prance, but holdontoyourshoehorn gallop)... but, I say lets get something truly universal working... let's hammer out the opcode definitions, and the translators and not worry about making the runtime engines yet... let's not worry about which side of the car we're gonna put the steering wheel on... the runtime engines are IMHO like -last- on the list... also, we can make a *generic* runtime engine, something that can compile under any compiler, if we adhere to *generic* routines. it'll be slower than EU, yes, but IMHO, UniEU is the best of the potential suggestions i've seen thus far as to how to get EU to the masses. >Writing a sequence engine is the hardest part, although >I think that sequences can be roughly be mapped to arrays. sure, def'nly, !easy. But, all C compilers i know of surely do support arrays, and i can almost envision the pseudocode needed to make arrays behave like sequences, at least for 'generic' runtime engines. almost, not quite tho... another thing, why do we have to talk C? i can think of *several* languages that have some good 'generic' routines/data types, that are multi-platformed. pascal for starters. another thing is that we (EU community) don't have to give out the code used to make the runtime engines, only the exe compiled for the platform. >Generating a Java .class file is another option. >The main appeal of this approach is that Java is already >ported to lots of different machines. not a bad thing. but does it have to be (as it sounds) an either/or choice? why not UniEU translators -and- EU->java & java->EU translators??? (assigned to 2 different teams, of course; after all, would you want anyone fooling around with java near you? ;) i see UniEU as potentially being 'better' than java anyway. furthermore, i think it'd be harder to implement EU within java as compared to other languages, but i haven't given that particular point all that much thought. >If you were really gung-ho, you could generate >a .java file (Java bytecodes) directly... or..... not. ;> *12.4% of 0.50 unnamed currency units float slowly to the ground* --Hawke'
6. Re: mac.exe
- Posted by Pete Eberlein <xseal at HARBORSIDE.COM> Sep 22, 1998
- 584 views
<snip snip longish stuff about macs, pointers and handles) I have to agree with Hawke on this one David... a C compiler on the mac should handle pointers just as if it were on DOS/WIN/UNIX/C64 whatever. The low level implementation of a memory address may be different, but the compiler will take care of all the memory locking/paging and offer the normal C programmming fashions. I'm going back to college next week and I will compile PEU on a Mac just to prove it can be done. Java bytecode translation - now that's an interesting idea. Might have to give this one some thought, and dig through some java docs. [discard] Anyone ever tried to throw away a sequence using an if statement? Let me forewarn ya - it ain't gonna make ex.exe happy. A discard procedure would be a welcome addition to the language... for now procedure discard(object o) end procedure will have to do.... and we'll just have to put up with the warning messages unless they're turned off. I can also see how Ralf's suggestion for discarding would work in the interpreter. For PEU, simply have the discard procedure pop off and free the last object on the stack. No type_checking, boolean test or possible code jump would be performed. In a tight loop you might see a difference. Laters, _______ ______ _______ ______ [ _ \[ _ ][ _ _ ][ _ ] [/| [_] |[/| [_\][/ | | \][/| [_\] | ___/ | _] | | | _] [\| [/] [\| [_/] [\| |/] [\| [_/] [_____] [______] [_____] [______] xseal at harborside.com ICQ:13466657 http://www.harborside.com/home/x/xseal/euphoria/
7. Re: mac.exe
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Sep 22, 1998
- 578 views
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDE678.EC318818 charset="iso-8859-1" Pete wrote: > I have to agree with Hawke on this one David... a C compiler > on the mac should handle pointers just as if it were on > DOS/WIN/UNIX/C64 whatever. I'll be quite happy to be proven wrong here - I'll be able to start using it on the Mac. > Java bytecode translation - now that's an interesting idea. Might > have to give this one some thought, and dig through some java docs. Let me know how that turns out! -- David Cuny ------_=_NextPart_001_01BDE678.EC318818 charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0"> <TITLE>RE: mac.exe</TITLE> </HEAD> <BODY> <P><FONT SIZE=2>Pete wrote:</FONT> </P> <P><FONT SIZE=2>> I have to agree with Hawke on this one David... a C compiler </FONT> <BR><FONT SIZE=2>> on the mac should handle pointers just as if it were on </FONT> <BR><FONT SIZE=2>> DOS/WIN/UNIX/C64 whatever.</FONT> </P> <P><FONT SIZE=2>I'll be quite happy to be proven wrong here - I'll be able to start using it on the Mac.</FONT> </P> <P><FONT SIZE=2>> Java bytecode translation - now that's an interesting idea. Might </FONT> <BR><FONT SIZE=2>> have to give this one some thought, and dig through some java docs.</FONT> </P> <P><FONT SIZE=2>Let me know how that turns out!</FONT> </P> <P><FONT SIZE=2>-- David Cuny</FONT> </P> </HTML> ------_=_NextPart_001_01BDE678.EC318818--
8. Re: mac.exe
- Posted by Jeffrey Fielding <JJProg at CYBERBURY.NET> Sep 22, 1998
- 566 views
I don't like Macintoshes, and I have never programmed one, but I have been developing a port of my Euphoria Pre-Processor for Java. Once in Java, it could be used to run Euphoria programs on any platform that supports Java. It wouldn't support any of the Win32 stuff since that is only on Win32 platforms, but it would support everything in the DOS version. I have also been looking into developing a Java class file reader/writer to translate Java to Euphoria and visa-versa, but it seems much harder, and I haven't gotten far with it. At least I have my Euphoria version of my pre-processor to base the Java version on. Jeffrey Fielding JJProg at cyberbury.net
9. Re: mac.exe
- Posted by Noah Smith <nhs6080 at UNIX.TAMU.EDU> Sep 22, 1998
- 564 views
You know, I kinda started this debate here, but I think I'm a little in over my head about the whole thing. I'll tell you what tho, if anyone comes up with anything compiled, send me the address of where to download it, I'll send that to my brother (who owns the Mac in question) and I'm sure he'd be willing to Alpha/Beta/Eat it with Relish test it. He's only programmed in Pascal -- 4 years ago and poorly at that-- and I think he's really getting discouraged trying to learn C. Especially since I can do things so easily in Euphoria. thanks in advance, snortboy
10. Re: mac.exe
- Posted by Matt Z Nunyabidness <matt1421 at JUNO.COM> Sep 22, 1998
- 565 views
- Last edited Sep 23, 1998
whats being an alpha tester? ------------------------------------- When it comes to programming languages, Euphoria is a cut above - matt1278 at juno.com and matt1421 at juno.com(and soon to be irisnmatt at prodigy.net. Then again, maybe not) Euphoria programmer _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]
11. Re: mac.exe
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Sep 23, 1998
- 583 views
>whats being an alpha tester? WHen developping a big or complicated program, it usually consists of multiple parts, some less dificult than others. Fox example, when Robert wrote ex.exe he would prolly started with a basic preproccesor, which he tested until he knew for sure, it did what it did. Then I assume he wrote the sequence engine.. same testing here.. then some of the built-in routines, some testing, then the machine proc/functions (graphics, and stuff) and finally the euphoria includes. All these part were only a small subset of functionality of the complete program, and alpha version are more to test if an approach (right?) will work... then when found the right approaches/techniques for those problems that seem to be the most complicated, then you combine most of it until some form of program. Now we call it a Beta version. We test, test.. hope not to find any too crucial problems, (so we have to rewrite a whole section) .. this is the place where we usually put a few hacks in it, if we did make a mistake in our original design. ("just make it work" - ideology) and we keep calling it beta versions until we cant find any new error, and when the crucial and simple errors are overcome, then we release it and call it the complete version. (however, some Companies call alpha versions -- beta versions and beta versions -- complete version, and use the audience to test their software, for example, companies like MS and Borland are pretty good at this. A lot of game designers as well.) Ralf
12. Re: mac.exe
- Posted by Hawke <mdeland at NWINFO.NET> Sep 23, 1998
- 591 views
Ralf Nieuwenhuijsen wrote: {someone asked (matt??)} >>whats being an alpha tester? ralf's answer is good. mine is: Being an alpha tester requires the innate need of watching your computer reboot more than once every ten minutes. Not just a desire, a need. You're world should revolve around watching the bios perform memory checking. You're very being should be defined by the number of times per hour that you see "Press <DEL> to enter setup". If you have experience in Beta Testing, but felt that the software under test was far too stable for your personal CPS (crash per second) ratios to be upheld, we are looking for you. Buy this game from us, for a mere ~60$ U.S., and you can feel the thrill of watching ScanDisk report lost clusters for weeks on end. Buy Now! [The following was a paid advertisement for Bugthesda Software, makers of BuggerFall and it's sequel BugtleSpire.]
13. Re: mac.exe
- Posted by Hawke <mdeland at NWINFO.NET> Sep 23, 1998
- 562 views
Jeffrey Fielding wrote: > developing a port of my Euphoria Pre-Processor for Java. SNIP >also a class file reader/writer to translate Java to Euphoria >and visa-versa, but it seems much harder, and I SNIP you go! *hands out morale and support snippets* --Hawke'
14. Re: mac.exe
- Posted by Kevin Sieger <simkin at ZEBRA.NET> Sep 23, 1998
- 570 views
- Last edited Sep 24, 1998
Hawke wrote: > Jeffrey Fielding wrote: > > developing a port of my Euphoria Pre-Processor for Java. > SNIP > >also a class file reader/writer to translate Java to Euphoria > >and visa-versa, but it seems much harder, and I > SNIP > > you go! > > *hands out morale and support snippets* > > --Hawke' Hmmm, the interesting thing here is that Java is supposedly slower than Euphoria already, so programming a Euphoria interpreter in Java would be like towing a Mercedes with A Ford Escort, would it not? IOW, perhaps it would be a useful learning tool, but I think it might be too slow to go anywhere serious. Kevin
15. Re: mac.exe
- Posted by Hawke <mdeland at NWINFO.NET> Sep 24, 1998
- 585 views
Kevin Sieger wrote: >so programming a Euphoria interpreter in Java would be >like towing a Mercedes with A Ford Escort, would it not? *snicker* >perhaps it would be a useful learning tool, but I think >it might be too slow to go anywhere serious. well, it depends you know? certain java apps/applets are not really involved in real time activities. how fast some apps run just isn't important in some cases... like a java program that converts text into pretty colors and saves the text and coloring to html... java programs that create menus and lists and dropdowns and forms and the like, they aren't that speed critical... what would be nice is that we could use EU to make these kinda programs and those programs would then run on a large variety of platforms. even puzzle games, card games, and some multiplayer (turnbased) games could be done and coded faster and easier with EU and still return decent execution times. it just depends on how the EU->java translation is done. if its a java program that is running and actively interpreting EU on the fly, that would likely be bad. if its a java program that converts .ex to java code (class files) then you might have something... --Hawke'
16. Re: mac.exe
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Sep 24, 1998
- 584 views
>Hmmm, the interesting thing here is that Java is supposedly slower than >Euphoria already, so programming a Euphoria interpreter in Java would be >like towing a Mercedes with A Ford Escort, would it not? IOW, perhaps >it would be a useful learning tool, but I think it might be too slow to >go anywhere serious. Now stuff is going to get messy. Sorry, Robert to break your marketing strategy, but Java is *not* nessecarily slower than Euphoria. There are 2 reasons why it was times 8 times slower than Euphoria: 1) Benchmarks and common use have little to do with each other. Robert got to choose the benchmark. 2) The Java Interpreter used was not of the new JIT technology. Which loads slower, and more memory troubling, however it executes *faster* .. I repeat .. *faster* However, again, Java is not Euphoria and speed is not easily compared. For example compare ASM and C++ using Watcom for example. ASM *in theory* and *in benchmarks* runs much faster, however when coding a complicated program, no human is capable of applying the same optimization as a smart compiler could. That is why most programs are written in C, where some small crucial parts where brainstormed about what the fastest possible code would be in ASM and then that code was inlined. Same goes for Euphoria. Many simpel safe tasks in Euphoria, take loads of work and run slowly in Java. Simply because the tools dont fit the goal. A screwdriver gives you more option than a hammer, however jamming nails in with a screwdriver is still harder than using a hammer. That is again what you call a *compromise*.. enough anology now.. Ralf
17. Re: mac.exe
- Posted by Matt Z Nunyabidness <matt1421 at JUNO.COM> Sep 24, 1998
- 592 views
Is your last name pronounced dkjgn8signng or nieoovenhayezen ------------------------------------- When it comes to programming languages, Euphoria is a cut above - matt1278 at juno.com and matt1421 at juno.com(and soon to be irisnmatt at prodigy.net. Then again, maybe not) Euphoria programmer _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]