From: Rick DeNatale on
On Thu, Dec 3, 2009 at 10:49 AM, Matthew K. Williams <matt(a)> wrote:
> On Thu, 3 Dec 2009, Walton Hoops wrote:

>> Heh same here actually... 10 years ago API Compsci ;-)
> Eeek!  I feel old.  I did AP CompSci back 21 years ago.  It was in Pascal
> then......

Don't feel so old, I got my BS in CompSci 35 years ago, Fortran, PL/I,
Lisp, Snobol..., punch cards, paper tapes, teletypes.

I don't know if Pascal even existed then.

Rick DeNatale


From: Michal Suchanek on
2009/12/3 Ken Bloom <kbloom(a)>:
> On Thu, 03 Dec 2009 00:49:57 +0900, Teodor Carstea wrote:
>>>C++ doesn't have a way to "initialize graphics mode"
>> Well, this is the way I do it in C++:
>> #include <graphics.h>
>> void main(){
>>   //initializing graphics mode
>>         int gdriver=DETECT, gmode, errorcode;
>>   initgraph(&gdriver, &gmode, "C:\\Progra~1\\BORLANDC\\BGI"); errorcode
>>   = graphresult();
>>   if(errorcode!=grOk) {
>>        cout<<"Graphics error!!!\n"
>>            <<"Press any key...";
>>        getch();
>>        exit(1);
>>   }
>> //...
>> //...
>> }
>> I'd like to make my ruby prog like this. Any Ideas? P.S.: If you have an
>> idea, please describe it in a way you would talk to a noob, for I'm
>> really green. Plus, I use Ubuntu, no comment.
>> Thanks!
> Wow! That's a blast from the past! I'm guessing it's either Borland C++
> for DOS (where screens actually did have "graphics mode" versus "text
> mode"[1]) or their library for Windows which simulated the old DOS
> library by opening up a window and drawing in that window. (I programmed
> for this emulation library 10 years ago as part of an AP computer science
> assignment.)
> I'm guessing that you're moving from your knowledge of old DOS/Windows
> and C++, you're moving to Linux and now you want to learn a nice shiny
> new language for programming in Linux, so you chose Ruby.
> If you're planning on writing GUI applications, you should either look at
> Ruby/GTK+ or QTRuby, both of which are good frameworks providing all of
> the standard widgets that you find in word processors, web browsers, and
> the like.
> If you want full screen graphics (or full-screen graphics in a window),
> which is often useful for game programming, you should look at Ruby/SDL.
> Ultimately you should take the time to learn a little of both.
> [1] FWIW, Linux has this too, but you only think about it that way if
> you're writing an X server or programming in svgalib. For the most part
> that view of the world is obsolete by about 20 years.

Well, actually this is not that obsolete. If you open an X window you
can use it exactly the same way (as long as the kind user does not
resize it for you). There is the Linux framebuffer console which works
pretty much the same (which is being obsoleted for some/most
chipsets). Yet as it is being thrown out through the door it climbs
back through the window in the form of KMS.

Writing X servers is not that uncommon, too. Linux/BSD ports on some
obscure platforms are in need of X server implementation/improvement
(ie. Nintendo DS - anyone would finish it?)

And since we will have KMS it should be much easier to throw away
Xfree86 and finally get some decent GUI system which is not patch on
patch of decades old cruft.

GRUB is currently in the process of implementing a graphics menu
system for eye candy, non-Latin language support, and non-VGA platform
support which (surprise!) has to deal with this 20 years old direct
memory access approach.

In fact, there is a windowing system (EWS) that is completely based
around emulated video memory bufffers and has no pre-made buttons,
canvases, pixmaps or anything like that. It's dead simple, fast
enough, end even has decent security.