Source for QBasic or QuickBasic
FB programs will run faster on modern computers than QB programs on modern computers, and in most cases will run faster on older computers as well. One of the most obvious reasons is that QB targets the 8086 processor, whereas FB was designed from the ground up to be run on modern CPUs. FB is ALWAYS going to be faster than QBasic in terms of execution speed on modern computers for the simple fact that QBasic is an interpreter (and a rather slow one at that) and FB compiles to a native executable. From what I understand, QB doesn't even compile to a proper executable but more of a bytecode stub that runs in BRUN.
Obviously, FB programs aren't going to run on a 286 or lesser CPU, whereas QB programs generally will. But who's using such obsolete systems these days? If you're looking to develop performant applications on modern systems, you're not going to look at QBasic or even QB. You can only push the limits of QBasic so much; you're not writing a realtime hi-resolution 3D engine in QBasic anytime soon...not until they invent 9GHz processors that run in 8086 mode. It simply doesn't have the calculation speed, nor can it take full advantage of modern video hardware. In FB, this isn't difficult to do, and has already been done dozens of times. Windows GUI applications, linear framebuffer SVGA modes, applications that run natively in Linux...all things QBasic could never do that are completely brainless in FB. About the only straw someone could grasp for is that QB 7.1 can develop applications that run in OS/2...but that's a major straw.
Lazy, stupid programmers learn to code in C# and buy 3GHz computers to make programs that are less functional and efficient (yet more flashy!) than similar programs written in C twenty years prior on 386-based machines running Windows 3.1. But thinking that "just code it better!" is the solution to the slowness problems of QBasic is silly when it's been shown countless times over the years that it is slow, inefficient, and above all else, limited in what it can pull off by itself. QB removes some of those limitations but even QB has limits that cannot be overcome. It's a harsh reality that a select few people are having a very difficult time coming to terms with.
The beauty of QBasic is in its simplicity. The beauty of FB is in its raw power. The beauty of this post is in its truth.
Obviously, FB programs aren't going to run on a 286 or lesser CPU, whereas QB programs generally will. But who's using such obsolete systems these days? If you're looking to develop performant applications on modern systems, you're not going to look at QBasic or even QB. You can only push the limits of QBasic so much; you're not writing a realtime hi-resolution 3D engine in QBasic anytime soon...not until they invent 9GHz processors that run in 8086 mode. It simply doesn't have the calculation speed, nor can it take full advantage of modern video hardware. In FB, this isn't difficult to do, and has already been done dozens of times. Windows GUI applications, linear framebuffer SVGA modes, applications that run natively in Linux...all things QBasic could never do that are completely brainless in FB. About the only straw someone could grasp for is that QB 7.1 can develop applications that run in OS/2...but that's a major straw.
Lazy, stupid programmers learn to code in C# and buy 3GHz computers to make programs that are less functional and efficient (yet more flashy!) than similar programs written in C twenty years prior on 386-based machines running Windows 3.1. But thinking that "just code it better!" is the solution to the slowness problems of QBasic is silly when it's been shown countless times over the years that it is slow, inefficient, and above all else, limited in what it can pull off by itself. QB removes some of those limitations but even QB has limits that cannot be overcome. It's a harsh reality that a select few people are having a very difficult time coming to terms with.
The beauty of QBasic is in its simplicity. The beauty of FB is in its raw power. The beauty of this post is in its truth.
Oh by the way...that Monopoly program doesn't compile in QB 4.5:
Code: Select all
BC C:\QB45\MONOPOLY.BAS/O/T/C:512;
Microsoft (R) QuickBASIC Compiler Version 4.50
(C) Copyright Microsoft Corporation 1982-1988.
All rights reserved.
Simultaneously published in the U.S. and Canada.
008D 000C CONST GO = -2
^ Syntax error
4025 0DBA CASE GO
^ Syntax error
6584 0DBA END IF
^ Subprogram error
69DD 0DBA END IF
^ Subprogram error
A095 0DBA Setup 0, GO, "?GO"
^ Syntax error
42029 Bytes Available
11787 Bytes Free
0 Warning Error(s)
5 Severe Error(s)
Press any key to continue
That's what I wanted to know.
But I can't call QBASIC slow becuase I came from TI-B.
Cycles once per a tenth of a second.
QB counts to somewhere in the tens of thousands by the time TI gets to 10.
But:
Runs 100 cycles per second (in TI 83 SE). So optimization can make a big difference. Maybe not enough, but still a difference.
But I can't call QBASIC slow becuase I came from TI-B.
Code: Select all
0->x
Lbl 1
Disp x
x+1->x
Goto 1
QB counts to somewhere in the tens of thousands by the time TI gets to 10.
But:
Code: Select all
For (X,1,1000)
Output(1,1,X)
End
For any grievances posted above, I blame whoever is in charge . . .
-
- Veteran
- Posts: 399
- Joined: Wed Mar 02, 2005 9:01 pm
- Location: Nashville, Tennessee
- Contact:
Leave off your parentheses.Mentat wrote:That's what I wanted to know.
But I can't call QBASIC slow becuase I came from TI-B.
Cycles once per a tenth of a second.Code: Select all
0->x Lbl 1 Disp x x+1->x Goto 1
QB counts to somewhere in the tens of thousands by the time TI gets to 10.
But:Runs 100 cycles per second (in TI 83 SE). So optimization can make a big difference. Maybe not enough, but still a difference.Code: Select all
For (X,1,1000) Output(1,1,X) End
*vomit*
Seriously, on a limited platform such as the TI-83(84)(+)(SE), you need every bit of optimization you can get.
Like when people do...
Code: Select all
900->dim(L6
For(A,1,900
A->L6(A
End
Code: Select all
seq(A,A,1,900->L6
Code: Select all
cumSum(binomcdf(899,1->L6
I usually do leave off parenthesis.
But you forgot something pretty vital to memory
A list of 900 takes up a lot of space.
And many of my programs are modelled more or less this way. Maybe not as fast, but I don't run out of memory and it's more flexible.
TI has too little RAM. Thus Archiving saves valuable memory, and protects data.
But in QB (QBASIC or QuickBASIC), the way to 'archive' is to save to something else and then write over the variables and/or strings.
But you forgot something pretty vital to memory
is better of asPatz QuickBASIC Creations wrote:Code: Select all
900->dim(L6 For(A,1,900 A->L6(A End
Code: Select all
GarbageCollect 'its under Catalouge. Saves Memory and RAM.
Unarchive LMYLIST 'just in case it's archived
900->LMYLIST 'the calc makes the list if it can't find the name
For(A,1,999 '999 is upper limit of list size
PrgmFunction 'Some Sub that returns the function of A as B
B->LMYLIST(A 'B can be a set of changing data from A
End
Archive LMYLIST 'Saves it to ARC, thus RAM acts like it isn't there
And many of my programs are modelled more or less this way. Maybe not as fast, but I don't run out of memory and it's more flexible.
TI has too little RAM. Thus Archiving saves valuable memory, and protects data.
But in QB (QBASIC or QuickBASIC), the way to 'archive' is to save to something else and then write over the variables and/or strings.
For any grievances posted above, I blame whoever is in charge . . .
-
- Veteran
- Posts: 399
- Joined: Wed Mar 02, 2005 9:01 pm
- Location: Nashville, Tennessee
- Contact:
Stoves,Stoves wrote:Anyone happen to know if the source code for QBasic or QuickBasic (interpreter or compiler) has ever been leaked? and if so, where it might be found?
Even if you had the original source code for QBasic, you would also need the corresponding original version of the C compiler, plus any libraries used back then, and also the assembler. Having all these exact elements would be miraculous. Another variable might be the actual operating environment, the hardware and the original operating system, used at the time to produce the executable code of QBasic.
The bottom line is that even given limitless time and money, I don't think you could ever put together a comparable working version of QBasic, let alone make enhancements to it.
Regards..... Moneo