Re: Compiler status
- Posted by Ben Fosberg <BenFosberg at WORLDNET.ATT.NET> Jul 11, 2000
- 576 views
Sounds to me like some people on this thread may be talking apples and elephants. Would someone sort these issues out for me; I'm getting really confused: 1) The "core language" is (PD)ex.exe for dos32 and (PD)exw.exe on Win32 (sorry, Linux folk, I don't remember your lingo). Is it being claimed here that the Win32 executable for the interpreter includes the dos graphics library? If not, those of us writing for Win32 aren't being "burdened" with the library, are we? If so, why? 2) Despite the fact that we all keep saying "compiler," I believe the gizmo Rob described was a "translator." You put in Euphoria and you get out C source, which you then feed into a C compiler. Unless Rob's gizmo and the (Watcom) compiler are both aggressively "anti-optimizing," I don't understand how the final binary will be any larger due to the translator's support for (dos library) graphics routines that aren't being called (because they aren't relevant) in a Windoz or Linux program. While I'm yapping again, just for the polling stats: I'm "programming" (almost) for DOS and Windoz on little slow machines and big fast ones. DOS is far from dead outside the small world of "developers," and Linux, et al., are a long way from common in the real world. Small executables are always nice and speed is always nice - occasionally even essential - regardless, but personally, I put big stock in not having to write a whole lot of code that someone else has already provided, so I like the libraries. But I think that adding more of them to the core executable is counter-productive. There are many occasions, even in Windoz, when you don't need Win32Lib, for instance, much as I like using it. And, thankfully, it keeps growing. What seems to me to be more useful in the long run is a resolution of the namespace conflicts, and perhaps even a "smart include" function in the binder. In any event, I would certainly defer to others on the choice of cross-platform graphics libraries. Ben Fosberg "Cuny, David@DSS" wrote: > Ralf wrote: > > > The fact is nobody uses [the DOS graphics library]. > > I guess that makes me a nobody. > > > I mean, it would make much more sense to add a > > platform independent GUI lib than to add a > > graphical lib that only works on Dos32. > > True, but no one is 'adding' a library. It's been part of Euphoria for quite > some time. > > You're talking apples and oranges here. There's a world of difference > between a fullscreen/framebuffer type of graphic system (like DOS has), and > a windowed graphic system (like the X Window System). If you just want a > cross-platform replacement for the fullescreen DOS graphics library, I'd > suggest SciTech's MGL library (http://www.scitechsoft.com/download.html), > which runs under Windows, Linux, DOS, OS/2 and QNX. > > Even if Robert added a cross-platform GUI, it seems to me that he would > still want to keep the DOS graphic library intact. > > > The year is 2000, may I remind you, nobody > > uses Dos anymore > > By the same criteria, 'nobody' codes in Euphoria, either. I do quite a bit > of DOS coding. > > > I dunno which, I suggest some one asks > > David .. he seen 'em all. > > You can find a good list of options at > http://www.geocities.com/SiliconValley/Vista/7184/guitool.html, and decide > if you agree with me or not. > > On the commercial side, Qt (http://www.trolltech.com/) and Zinc > (http://www.zinc.com/products/zaf/zaf.htm) are probably the best options. > Both are C++ based, and Qt uses a pre-processor, so there would be some > challanges for Robert here, but they are surmountable. Both libraries seem > to have fairly small footprints, and Zinc even supports DOS and Macintosh. > But I doubt that Robert could afford either option - or that we'd be willing > to buy Euphoria to support the cost of the toolkit. > > On the free side, V (http://www.objectcentral.com/vgui/vgui.htm) and > wxWindows (http://206.101.232.131/) are probably the best options. V is very > nice (and easier to learn), but wxWindows seems far more complete, > supporting many more platforms - even the Mac. Both libraries are in C++, so > there are no doubt serious issues to getting either working. On the other > hand, I know that Python bindings exist for wxWindows, so it should be quite > possible. > > I'm quite fond of a number of other toolkits that don't offer complete > solutions, such as: > > GTK+ (http://www.gtk.org) > Microwindows (http://microwindows.censoft.com/) > WINE (http://www.winehq.com) > OpenGL (http://www.opengl.org/) > > OK, bottom line: if Robert were to graft a cross-platform library onto > Euphoria, I'd highly suggest using wxWindows: > > - Free, even for commercial purposes > - Complete - cross-platform fonts, printing, etc. > - Well documented > - Well supported > - Runs on Win32, GTK+ and Macintosh > - Pending ports include BeOS and QNX > - wxPython shows can be used in scripting language > > Personally, I'd love to see a port to wxWindows. > > -- David Cuny