Announcement

Collapse
No announcement yet.

Converting qbasic to executable

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Converting qbasic to executable

    I am an old-time qbasic user and would like to convert my qbasic .bas programs to stand-alone applications. QuickBasic 4.5 does this but only allows small sized programs. My programs are too large for QB4.5 to convert. Is there a PowerBasic (or other) option that will accomplish this?

  • #2
    Originally posted by Bryan Beaulieu View Post
    I am an old-time qbasic user and would like to convert my qbasic .bas programs to stand-alone applications. QuickBasic 4.5 does this but only allows small sized programs. My programs are too large for QB4.5 to convert. Is there a PowerBasic (or other) option that will accomplish this?
    Hi Bryan. The answer is "yes"! Please visit our web site (http://www.powerbasic.com/products/pbdos/) for information about our PB/DOS compiler. You may need to make some small changes to your source code but the syntax is more than 95% the same.

    Comment


    • #3
      Have you checked out all available tips for handling big programs in QB 4.5 -- CHAINing, LINKing of libraries, etc.? Ethan Winer's book on "BASIC techniques & utilities" (Ziff-Davis Press, 1991) covers the topic nicely, I'd bet. Winer has a website on which you might be able to get his book and relevant articles free; and in fact these might be available on the PowerBASIC downloads.

      QBX (a.k.a. PDS or Microsoft BASIC 7.1) is another route you could go, but anything it or QB 4.5 can do PowerBASIC 3.5 for DOS can do better, especially when you consider the quality of support you can get from the PB forums. PowerBASIC 4 for Windows consoles (PBCC) and PBWin 8 will in turn put PB-DOS to shame when it comes to handling big programs & data sets.

      Converting QB to PB-DOS is usually easy; converting it to PBCC is sometimes easy & sometimes (e.g., if you use graphics) not; & converting it to PBWin is enough work to make most programmers strongly consider writing a new program from scratch. I doubt that any other brand of BASIC is any more compatible with QB than PB 3.5, but I confess that I haven't tried them all, by a long shot.

      Comment


      • #4
        if it's a text program, using PBCC (console compiler) would be an option.

        With qb, (qb4.x) that is 4.0, 4.5 etc you can divide programs using some programs with just subroutines and functions in them and no executible code
        in the "main" program area of the other bas programs then using the load function, of the editor load the bas programs one at a time.

        Once this is done, the editor will make a mak file containing these program names and they will be loaded whenever you load the 'main' program again.

        They advantage of this is that each program (.bas file) will be compiled individually then linked together allowing programs of 100-200k or more possibly. While this is not large by today's standards it is in qb terms.

        You may already know of this little trick but just thought id put it out there in case.

        Example: not tested

        program1.bas
        -------------
        DECLARE SUB PRINTDATE(DT$)
        common dt$
        input "Enter date mmddyy".dt$
        printdate dt$
        while inkey$="":wend
        system

        program2.bas
        -------------
        DECLARE SUB PRINTDATE(DT$)
        common dt$
        sub printdate(dt$)
        print left$(dt$,2);"/";mid$(dt$,3,2);"/";right$(dt$,2)
        end sub

        program1.mak
        -------------
        program1.bas
        program2.bas

        then when you load it you can see all the programs and subs with the F2 key.
        program1.bas and program2.bas will compile separately then be linked together for program1.exe

        The common dt$ really is not needed but merely to show what code (for example) can be in program2.bas in the main area
        (common statements for example which are not executible code)
        Last edited by Fred Buffington; 7 May 2008, 10:47 PM.
        Client Writeup for the CPA

        buffs.proboards2.com

        Links Page

        Comment


        • #5
          FWIW, if you are careful about what functions you put in which modules, and in which modules you use the event functions (ON ERROR, ON KEY etc), using separately-compiled modules can dramatically reduce the size of the executable and enhance the performance big time.

          You might have to use the command-line compiler 'bc' specifying the exact options you want for each module, but you can put all the 'bc' plus the 'link' commands into a batch file. Something tells me that if you let the IDE handle the compile, if any module needs event-checking code then all modules are compiled with it; or maybe it's the IDE always uses all the options. That's worth double-checking.

          But it's a lot easier to control the specific module-compilation options using the PB/DOS option "$COMPILE UNIT" to create the separate modules.
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Actually, the older a version of PowerBasic you can find, the more compatibility between it and the QBasic and QuickBasic dialects. I had a copy of PowerBasic 2.1 that accepted a large QuickBasic source code that was unstable and sometimes ran out of memory, and it recompiled with PowerBasic with no problems. In fact, I was able to edit the source code and expand a lot of really compressed multistatement lines into a more readable one statement per line form with proper indentations, all of which demanded more memory, and PowerBasic had no problem handling it.

            PowerBasic kept improving itself, leaving QuickBasic way behind. So while it's compilers and language syntax are considered a superset of the old QuickBasic language, it evolved in other ways that make it somewhat hard to automate the process of converting from one dialect to the other. For instance, the CHAIN method that Microsoft adopted to split a large program into overlapping segments, with one calling the next, has no counterpart in PowerBasic, because PowerBasic allows you to use all of available memory for your programs and data.

            The superior memory management model that came with Windows, and many other
            advance features of Windows, gave PowerBasic a new lease and direction to follow in their continued development. But moving ahead also means leaving behind. So as a rule, conversions are easiest going from QB to PB/DOS, somewhat harder in going from QB to PB/CC, and might take serious rethought if moving from QB to PB/Win.

            Comment


            • #7
              For instance, the CHAIN method that Microsoft adopted to split a large program into overlapping segments, with one calling the next, has no counterpart in PowerBasic
              ???

              I think that would be accurate except for the PB function "CHAIN," itself futher supported by the $COMPILE CHAIN metastatement... at least in PB/DOS.

              There is no counterpart in PB's Windows' compilers.
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                QBasic Executables

                There is a program posted on the Internet called QB2C, which stands for QBasic to C. It converts source code into ANSI-C code, which then can be compiled, so you end up with an executable file. It is only intended on platforms that support X11 graphics, which would typically be some version of Linux. However, there are packages that add X11 support to Windows, which makes for the possibility of taking existing QBasic programs and compiling them to run on Windows, Linux, and even MacOS. This would be a compiled executable, not just a script-based interpreter.

                PowerBasic offers much more powerful compilers and a greatly expanded language, but at present it is strictly targeted at DOS (PB/DOS) or Windows (PB/CC and B/Win, although PB/DOS can work there as well).

                PB/DOS can take advantage of both Expanded and Extended memory when it is present. I also often set up a RAMDrive for fast file read and writes, which was a great help sometimes. As a consequence, I never found it necessary to use CHAIN with PB/DOS, which made program development straightforward.
                In fact, I had forgotten that it even existed as an option.

                The mention of QB2C was just to make you aware of what might be possible options. I've not worked with the product, but what I read was that it has
                some stiff syntax rules that may make it difficult to parse some source files.
                There is another tool mentioned that can help with reformatting the source so that QB2C can work with it. Then of course you have to compile under C, and verifying the translation could be somewhat challenging. But you could try it, just to see how well it works, and whether it might be the right tool for your needs.

                Comment


                • #9
                  Donald,

                  I have been using xmsdsk.exe by Uberto for windows 98. Still havent tried a ramdisk for XP as Uberto is for 98 only. I like using a Ramdisk especially for copying files into another folder, and a scratch area.

                  What do you recommend ?

                  Comment


                  • #10
                    Originally posted by Nick Luick View Post
                    Donald,

                    I have been using xmsdsk.exe by Uberto for windows 98. Still havent tried a ramdisk for XP as Uberto is for 98 only. I like using a Ramdisk especially for copying files into another folder, and a scratch area.

                    What do you recommend ?
                    http://www.mydigitallife.info/2007/0...d-2003-server/
                    http://members.fortunecity.com/ramdi...amdiskfree.htm
                    http://www.picobay.com/projects/2006...isk-drive.html
                    http://channel9.msdn.com/ShowPost.aspx?PostID=19803
                    http://members.fortunecity.com/ramdi...ramdiskent.htm
                    http://www.speedguide.net/read_articles.php?id=131
                    http://www.planetamd64.com/lofiversi...hp?t12230.html

                    The idea of using a RAMDisk or RAMDrive as part of Windows is not all that
                    common, but was almost a necessity under DOS. Yet the advantages of having a fast, volitile drive, and one that provides for data sharing between applications, can offer a real advantage. Above are just some links I found on the subject.

                    Comment

                    Working...
                    X