PDA

View Full Version : Working on GUI project coded in BASIC



jjzcp
September 15th, 2005, 06:58 PM
Hi, I am working on a simple GUI system writen in BASIC, so i can use it on any computer with a basic compiler, which is just about any old computer. I am about 1/3 done and have to fix some bugs, but when i am done if anyone is interested i will happily distribute the code. I estimate i will have this thing done in a couple of months, because i only work on it when i have time which is only an hour or two a day. Please post your thoughts about my project.

MystikShadows
September 15th, 2005, 07:38 PM
Hi jjzcp,

A GUI in BASIC huh? I'd definitaly love to hear more about it. Which basic compiler are you using for instance? Do you happen to have a few basic screenshots or layouts you could show us? What style of GUI will you be implementing? More of a Window like GUI or a Mac like GUI or GEM like GUI or maybe a Unix like GUI?

What do you plan to put in your GUI? do you plan on making tools for your GUI (image editors, text editors, calculators and other that will help make your GUI usable)?

I definitaly want to hear more about it. Also I would like to say that if you happen to be using QBasic or QB or the PDS or VB-DOS even, you might like to take a look at these following websites.

Data Components GUI Reviews
http://qbasicgui.us.tt/

Where you'll find no less than 184 GUI that were made in BASIC, it might help inspire you to see what you could add in your GUI and how you could make it look, feel and operate.

Also there is Jacob Palm's GUI development website:
http://www.jacobpalm.dk/

Where you'll find a bunch of users that are currently working on QB related GUI projects. It's a great place to ask questions, and get answers as far as GUI development in BASIC (QB family of compilers) it also has GUI reviews as well.

Since I don't know much about your GUI and have no screenshots or documents to read about it it's hard to post comments on it. But I think the idea of making a GUI (BASIC or other language) is a good one since I believe Windows and KDE and Mac OS/X are outliving their usefulness as in there's no breakthroughs anymore in GUIs today. It's all evolution not revolution and I think a revolution might be exactly what we need :-). But that's just me and don't quote me on that. we'll see what the future hold, that's all I can say :-).

Tell me more :-)

jjzcp
September 17th, 2005, 05:37 PM
:onfire:
Hi. First off I am using basic that came with DOS 2.11 so its not very capable with only 4 colors to choose from and the computer i am writing it on is a tandy 1000 with 256k, and secondly i think i will need to wait to get my freinds apple 2 to finish development due to the different gosub command. I will show you the difference.

Tandy 1000

10 print "1"
20 print "2"
30 gosub 40: print "3": end
40 print "4"
50 print "5": return
run
1
2
4
5
3

other 1980's computer with basic

10 print "1"
20 print "2"
30 gosub 80
40 print "3"
50 print "4"
60 gosub 80
70 stop
80 print "5"
90 return
run
1
2
5
3
4

carlsson
September 18th, 2005, 02:24 PM
Umm.. are you sure the latter output should not be 1 / 2 / 5 / 3 / 4 / 5 ?

Since the two programs are quite different and give different output, I don't understand the comparison between Basic dialects. It is true that some Basics allowed more than one statement on each row, but is this what you're trying to illustrate?

When you say GUI, do you mean only a menu system, or something more complex with windows, scrollbars, menus, buttons, requesters and so on? I think a more complex one may be difficult to write in portable Basic, unless it consists of several parts of which one is machine specific and then a general layer.

Terry Yager
September 18th, 2005, 02:28 PM
Yes, 1,2,5,3,4,5 would be the correct output of that code all right (because the second GOSUB command in line 60 branches to line 80 and PRINTs the numeral "5" a second time at the end of the program).

--T

jjzcp
September 19th, 2005, 07:19 PM
Yes you guys are correct on the code output and i fainlly got it to work! Thanks for the help. :o :D

CP/M User
September 23rd, 2005, 02:35 PM
"jjzcp" wrote:

> Hi. First off I am using basic that came with DOS 2.11 so its not very
> capable with only 4 colors to choose from and the computer i am
> writing it on is a tandy 1000 with 256k, and secondly i think i will need
> to wait to get my freinds apple 2 to finish development due to the
> different gosub command. I will show you the difference.

Yeah, I was going to say that if you wanted 16 colours to use the Non-
BIOS CGA mode (160x100x16), but will obviously lead to portability
issues. A tandy might actually support this (I believe a PC Jnr can) - but
like I said...

I don't particularly like BASIC - cause it can be so cluttered & confusing
(GOSUB is perhaps my favourite statement - GOTO is clearly the Worst!).

Carlsson, the whole problem with GUIs is portability, which is where
Libraries come in useful - your program code could be the same, which
can access a number statements from Libraries & those in turn would
have the machine specifics.

If you write a library which follows the GSX guidelines I think you could
get something which may work on a Tandy, DOS, CP/M environments.

CP/M User.

mbbrutman
September 25th, 2005, 04:46 PM
Is a GUI in BASIC on an older machine even feasible?

If you are talking about a specific program using a graphical user interface, then sure, there were lots of programs done in BASIC that used a GUI. Any drawing program would count.

If you are talking about a general purpose operating environment that is driven by a GUI, that implies the following:

- The operating environment can launch other programs.
- The operating environment provides library routines for those other programs to use.

I think that even with these two modest requirements, a GUI operating environment done in BASIC is tough. I'm not talking about things like multi-tasking, events, or anything like that .. I'm just talking about providing consistent look and feel using a GUI.

To do this in interpreted BASIC you'd have to restrict yourself to other BASIC programs that include the essential parts of the GUI in their code. This is because normal interpreted BASIC on an IBM clone doesn't do overlays, libraries, etc. Unless you start playing tricks with assembly language and managing memory to keep these things resident.

The other major problem with interpreted BASIC is the speed.

A compiled BASIC looks more like a DOS program, so you can start to use DOS memory management to keep things resident. You can also create library routines for your other programs to link to. And the speed is acceptable.

I wrote a simple program launcher in BASIC many years ago on a PCjr. It would show the list of BAS programs on the diskette, and let you move the cursor around under joystick control to pick the one you wanted to load and execute. That seems like a kindergarten program assignment compared to this. :-)

CP/M User
September 26th, 2005, 02:47 AM
"mbbrutman" wrote:

> Is a GUI in BASIC on an older machine even feasible?

> If you are talking about a specific program using a graphical user
> interface, then sure, there were lots of programs done in BASIC that
> used a GUI. Any drawing program would count.

I guess if they were going for this approach, writing a menu driven GUI with a simple set of programs could be the go, with a Text Editor, Simple Program for Doodling Graphics (lines & Pixels), Printing Program & a game of some sort. Files could be saved & loaded. BASIC maybe capable of doing.

> If you are talking about a general purpose operating environment that
> is driven by a GUI, that implies the following:

> - The operating environment can launch other programs.
> - The operating environment provides library routines for those other
> programs to use.

> I think that even with these two modest requirements, a GUI operating
> environment done in BASIC is tough. I'm not talking about things like
> multi-tasking, events, or anything like that .. I'm just talking about
> providing consistent look and feel using a GUI.

Oh yeah, this is another thing in itself. I think you could get away with it on some BASICs but your more or less moving into the QBASIC or PowerBASIC scale. These BASICs would move you to something which looks more like Turbo Pascal.

Another 8086 Compilable BASIC to look at is MoonRock, you can even get your Inline Assembly into it. This BASIC looks a little bit like SmallC though! It maybe still on the 'net (which was how I found it), but unfortunately I haven't seen much to go with this programming language.

> To do this in interpreted BASIC you'd have to restrict yourself to other
> BASIC programs that include the essential parts of the GUI in their
> code. This is because normal interpreted BASIC on an IBM clone
> doesn't do overlays, libraries, etc. Unless you start playing tricks with
> assembly language and managing memory to keep these things
> resident.

> The other major problem with interpreted BASIC is the speed.

Many people have said this, yet I have trouble comming to grips with it. In my trials though I've been testing Compiled TP programs with Locomotive BASIC on my Amstrad CPC (sure it's not GWBASIC or QBASIC), but Locomotive BASIC used to get hammered by Computer Mags Vs. Assembly. Sure if you do Sprites, you write it in Assembly (then make it an RSX - to access it from BASIC!)
In my trials a compiled TP 3 program was still slow - simply from Calculations & using Inline Machine Code to draw those Calculations to screen. I simply found calculations on this machine processed the calculations much faster in Interpreted BASIC! ;-)
It wasn't until I wrote a routine to produce calculations required for the program which stored them into an Array, I found Turbo Pascal was extremely quick at drawing the same result.

BASIC didn't do arrays in the same fashion (difference is CONSTant array's weren't possible),so it needed to read it from DATA statements & put it somewhere (which slows it down consideribly), the solution was to write a small program which got the values, POKE it (using a special 16Bit Poker which would be accessible from BASIC! ;-) & save it as a DATA file.

The other program could then read those results - I used a lot of assembly in it for it to gather the 16bit number & then draw it.

> I wrote a simple program launcher in BASIC many years ago on a
> PCjr. It would show the list of BAS programs on the diskette, and let
> you move the cursor around under joystick control to pick the one you
> wanted to load and execute. That seems like a kindergarten program
> assignment compared to this. :-)

It sounds as though it could be something which could be built on. For Example, is there a way for that program to get association from files & display depending on what type a file is display some type of Icon for certain file with a Filename below it, instead of having Text for the filename, turn it into a graphic & have a style of text.
The ol' Locomotive BASIC had the ability of TAGging the Text, turn it into a graphic (using MOVE) in connection with PRINT! Unfortunately I have no idea exactly how it grabs it, but you'd also want to modify which I don't know too much about either.
My closest example of TAG in TP / SmallC / Assembly uses an array (to represent a character) & a routine in which displays it. Basically speaking, it plots the little pixeks found in the array.

CP/M User.

mbbrutman
September 27th, 2005, 06:34 AM
The speed of interpreted BASIC is going to be horrible compared to a compiled BASIC program. There is no way around it - the interpreter is a fairly complex program. The interpreter has to read the next line of code, tokenize it, skip comments, etc. Compiled programs don't have this overhead.

You bring up a good point though. If most of the time is spent outside of the interpreter in a ROM routine, or if you can offload the processing to hardware (sprites), then you are not spending as much time in the interpreter and the relative penalty is smaller. But I would think that is the exception, not the rule - most interpreted BASIC programs are going to spend a long time in the BASIC program and interpreter, not the ROM routines. (Especially on a PC, since so much of the ROM routines are not used by the interpreter, as it insists on doing things itself.)

On a faster machine it's a moot point. I've never had a performance issue with GWBASIC on an 1100 Mhz Athlon. But using Cartridge BASIC or BASICA on a PCjr running at 4.77Mhz takes an eternity compared to the compiled equivalent.

Another speed issue is the algorithm that is being used. Let's contrive an example - looking up SINes and COSines of numbers. If interpreted BASIC uses a table lookup while your compiled program tries to compute it using floating point math, I'm pretty sure the interpreted BASIC is going to do it faster. Point being, a good algorithm is the key no matter what the environment.

Many years ago I started using Zbasic instead of the interpreted BASIC on the PC. Zbasic is a compiler, not an interpreter, so I lost the ability to interact with the program. But the speedup was well worth it, as were the advanced functions:

- structured programs without line numbers
- function calls
- inline assembly language
- overlays and program chaining

This was in the 1985 or 1986 timeframe - it was pretty advanced at the time.

Zbasic was available for many platforms, including CPM. Eventually it morphed into FutureBasic on the Mac. I've tried to find the last version available for the PC, but the authors probably want to forget that part of their lives. :-)

linster
October 13th, 2009, 12:01 PM
I've written a GUI in QuickBasic 4.5 called Linster OS.

you can find it here: http://linster.moved.in

If you need a nice widget toolkit (not written by me), some of my programs use QBobject, which is included in the zip file. (If not email me @ linster250@gmail.com)

It comes with full documentation and source code.
The installer program I wrote is buggy, just extract lin.zip into a folder and run gui.bat.

cgrape2
October 13th, 2009, 12:05 PM
Thanks for the link.I'm anxious to give your GUI a try.
cgrape2

linuxlove
October 15th, 2009, 08:14 AM
The whole program is a bit buggy.

cgrape2
October 15th, 2009, 11:45 AM
Exactly!It's a very good program to get the feel of debugging with,in Basic.
I've been trying to relearn Basic and it's slow going so far.This should provide a pretty good exercise.
cgrape2

linuxlove
October 16th, 2009, 06:48 AM
it's also quite slow on minimum system requirements. this is i think, just natural QuickBASIC. it would be much faster if he knew about MEMWRT, which makes Mike C.'s RockIRCd so fast.

Mike Chambers
October 16th, 2009, 05:17 PM
it's also quite slow on minimum system requirements. this is i think, just natural QuickBASIC. it would be much faster if he knew about MEMWRT, which makes Mike C.'s RockIRCd so fast.

nope, like i've said before krille's MEMWRT ASM routine is just a way to copy a given string directly to a given location in RAM. it's great for fast graphics output and copying large amounts of other data somewhere from a string instead of using a billion POKE commands.

rockircd has zero reason to use memwrt, and it does not. the ircd is 100% QB 7.1 PDS except of course for the TCP/IP stack it accesses with interrupts.

Mike Chambers
October 16th, 2009, 05:28 PM
I've written a GUI in QuickBasic 4.5 called Linster OS.

you can find it here: http://linster.moved.in

If you need a nice widget toolkit (not written by me), some of my programs use QBobject, which is included in the zip file. (If not email me @ linster250@gmail.com)

It comes with full documentation and source code.
The installer program I wrote is buggy, just extract lin.zip into a folder and run gui.bat.

interesting concept for QB, but it's extremely buggy and i don't think you could really call something that doesn't handle any sort of multi-tasking an OS. actually i couldn't even quite log in unfortunately. clicking login didn't seem to do anything. :(

looks like when you load an app in it, it just calls another EXE file that runs while keeping the desktop drawn in the background. btw if you want to fix the bug where the mouse leaves an imprint of the old graphic data that was there when something is changed over it, you should hide the mouse during graphic updates in that area, and then have it show again when the new graphics have been drawn.

writing a true OS in QB alone really isn't possible. you could definitely use it as a way to coordinate compiled routines from other languages like C and ASM to handle multitasking, memory management, allocation, virtual memory, timeslicing, etc. QB on it's own is far too limited.

syntax
October 16th, 2009, 06:16 PM
LinsterSoft reminds me of Microsoft, except Microsoft sucks a whole lot less. Also, LinsterOS reminds me of Microsoft Windows, except it isn't as bold in it's claims of capibility. You make LinsterOS sound like it's the second coming of OS/2 or even BeOS. "LinsterOS can massage your feet!" "LinsterOS can get you a girlfriend!". Fact is, LinsterOS can't even do what it claims to do. Multimedia!? It can't play sounds. It can't even do 800x600x32 graphics.

And educational? If you want to learn how not to design an OS, then it is educational. Security too. How is it secure? Does it use UNIX-ish security practices? Or is it just security through obscurity? LinsterOS doesn't even seem as capable as Windows 1.0. Hell, it doesn't even seem as capable as GEOS/GeoWorks for the C64, which ran in under 64k of RAM.

Now, I don't want to sound too hard on you, but LinsterOS sucks. If it came down to having to use LinsterOS or Windows ME, I'd choose Windows ME. If it came down to using LinsterOS or GEOS, I'd probably choose GEOS.

If you're site wasn't so extravagant on LinsterOS's claims I wouldn't be as hard. If you described it as what it was, a simple GUI made in QuickBasic for DOS, I wouldn't be as hard. LinsterOS has so much potential. Less marketing and more code, and LinsterOS could finally do what it claims to do.

mbbrutman
October 17th, 2009, 05:46 AM
I thought the comments about how buggy it was were a little harsh until I read the last comment. Wow ..

Nobody should be taking that project too seriously. It reminds me of what I thought software engineering was when I was a kid 25 years ago. It's not a serious attempt at a GUI shell or an OS, and I'm sure they know about it's short comings. I think the claims on the web site and the 'Certificate of Authenticity' give things away. How about "After talks of hostile takeover disintegrated, LinsterSoft and PiSoft are now peacefully merging to promote synergy in the BASIC applications market." as another clue?

linster
October 17th, 2009, 09:38 AM
Yep, LinsterSoft was actually born out of my desire to finish the project, and put a nice home-made software box on my shelf as a trophy of Linster OS :D

PiSoft is actually a fake company made by my friend, who writes programs for his TI-83 :D They actually wrote the original MathTools :)

I started writing Linster OS 2.0 way back in 2005-6 when I was in Grade 7 :)

After sitting on a shelf untill 2009, I decided to finish the project, just to say I have finished one of my projects (I'm that sort of person, never finishing what I start)

And no, I wouldn't use Linster OS as a "daily driver" anywhere either :P

PS: Linster OS dosen't have any task-switching at all, new windows are just seperate exe's drawn over the old ones. When they exit the desktop is redrawn :P

I'll have some more info later today, but I gotta go.

Mike Chambers
October 17th, 2009, 10:40 AM
Yep, LinsterSoft was actually born out of my desire to finish the project, and put a nice home-made software box on my shelf as a trophy of Linster OS :D

PiSoft is actually a fake company made by my friend, who writes programs for his TI-83 :D They actually wrote the original MathTools :)

I started writing Linster OS 2.0 way back in 2005-6 when I was in Grade 7 :)

After sitting on a shelf untill 2009, I decided to finish the project, just to say I have finished one of my projects (I'm that sort of person, never finishing what I start)

And no, I wouldn't use Linster OS as a "daily driver" anywhere either :P

PS: Linster OS dosen't have any task-switching at all, new windows are just seperate exe's drawn over the old ones. When they exit the desktop is redrawn :P

I'll have some more info later today, but I gotta go.

i totally am with you on never finishing projects lol. my QB programs usually get close to finished but then i get too lazy to refine them and really call it "complete"

EDIT: i guess LeetIRC is more or less "complete" but i really need to replace the POKE routines for drawing the text to the screen with ASM memory copies from the buffer array for good performance on anything less than a 386.