Announcement

Collapse
No announcement yet.

PB Dos on 64 bit

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

  • Frank Cox
    replied
    PB/DOS on 64-bit Linux

    I have been using PB/DOS on Linux for some period of time. Details here: http://www.melvilletheatre.com/artic...nux/index.html

    I have recently been experimenting with PB/DOS on Fedora 8/x86_64, i.e. 64-bit Linux. The good news is that DOSEMU runs fine on this machine now that I have compiled it for x86_64 (which was reasonably painless process, by the way.)

    PB/DOS itself runs fine on x86_64, and programs compiled with PB/DOS also run fine.

    The bad news is that PB/DOS programs (and every other DOS program that I've tried so far, though I don't use much other than PB/DOS) run approximately 13 times more slowly on x86_64 than they do on the very same computer with Fedora 7/i386, i.e. 32-bit Linux. This is not as big of an issue as it may initially appear, because even 13x slower on a 3+GHZ computer is still much faster than computers were running when DOS was king of the hill.

    For an interesting description of why this is, you may want to read this brief article:



    My conclusion so far is that if you want to run the occasional DOS program (like PB) on Linux, then x86_64 may be worth using depending on what other native Linux programs you normally run. On the other hand, if you are setting up a server for the main purpose of running DOS programs on it (like I do) then i386 (32-bit) Linux is the way to go. There are other pluses and minuses to running x86_64 vs i386 that are beyond the scope of what I'm writing here.

    I intend to update my PB/DOS on Linux article referenced above to include information about x86_64 but haven't quite got around to that quite yet. Writing this message just now sort of reminds me that I should do that, so I may work on that later today or tomorrow.

    Leave a comment:


  • Nick Luick
    replied
    As per Microsoft one can run a virtual 16 or 32 bit system

    Using Virtual Machines as an Alternative
    The alternative to dual booting is to use Windows XP Professional x64 Edition as your operating system and install an older, 16- or 32-bit operating system into a virtual machine running within the x64 system. The beauty of this solution is that you can have your legacy operating system available any time you need it, without having to leave what you're doing. Heck, you can run it all the time if you want

    Leave a comment:


  • Robert DeBolt
    replied
    Originally posted by Giuseppe Belziti View Post
    Hi,
    How I do to run a PB Dos application on 64 bit SO.
    I have feel of WOW64.EXE, but where I find it?

    Thanks
    Giuseppe
    From Dell: Introducing Microsoft Windows Server 2003 x64 Editions for the Intel EM64T Platform, page 54:

    WOW64 does not support 16-bit applications, including the 16-bit WINNT.exe application.
    From Dr. Dobbs, we have the definition for WOW64:

    However, for Windows 64-bit to be successful, it needs to ensure that current 32-bit applications are supported. Consequently, the migration from 32-bit to 64-bit will take time, during which both 32-bit and 64-bit applications need to work side by side. To support this shift, Windows 64-bit edition includes a subsystem known as "WOW64."

    Thus, it does seem impossible to run 16-bit DOS programs on a 64-bit cpu. Even creating a 16-bit partition on a 64-bit HD seems impossible.

    It appears, that you may have to invest in some old 16-bit computers.

    Leave a comment:


  • Marco Pontello
    replied
    As Steve mentioned, the free DOSBox should do the works (it let run correctly many old DOS games that does a lot of strange tricks, so...).
    Since it's a complete emulatore, the CPU & the OS of the host system doesn't affect its workings; a virtualizer, instead, like VirtualPC, VMware, etc., won't do the trick.
    Off course the emulated system will be slow(er), but that probably won't be much of a problem.
    You may also try QEMU, but it will be a bit more complex to setup.

    Bye!

    Leave a comment:


  • Giuseppe Belziti
    replied
    Originally posted by Giuseppe Belziti View Post
    I use and I work with PBCC and PBWIN too, but I have also many application in MsDos. For this reason I should want to execute some MsDos programs at 64 bit, I cannot to transform all programs in PBCC.

    Someone can help me?
    My problem is that I have'nt many leisure for to transform all programs in PBCC.

    Leave a comment:


  • Steve Rossell
    replied
    You might look for a program called DOSBox and see if it will run 16-bit applications on a 64-bit version of Vista. I would be worried about BIOS calls and how that is supported, but you can always try it. You could also try MS VirtualPC or even a DOS boot disk to run these 16-bit applications.

    Leave a comment:


  • Roger Garstang
    replied
    So are you saying that some machines will only run DOS and not Windows and others Run WinXP/Vista 64bit, so you still need DOS? I don't believe there is anything PBDOS can do that can't be done in PBCC other than maybe some of the old linking techniques, maybe some direct port access at the hardware level, and some specific assembly calls. I only am required to use PBDOS on PCs and old handhelds that don't support Windows.

    Also keep in mind that you can still run 32Bit Windows on most 64bit CPUs. What is some sample code you have that won't work in PBCC?

    Leave a comment:


  • Giuseppe Belziti
    replied
    I use and I work with PBCC and PBWIN too, but I have also many application in MsDos. For this reason I should want to execute some MsDos programs at 64 bit, I cannot to transform all programs in PBCC.

    Someone can help me?

    Leave a comment:


  • Steve Rossell
    replied
    64-bit Versions of Windows (Vista, x64, and Server 2003) have no support for 16-bit applications. 32-bit versions of Windows Vista do support 16-bit applications. Your only real choice to is upgrade your 16-bit DOS applications to 32-bit Windows applications.

    This is not as daunting as it might seem. We have the PowerBASIC Console Compiler. A console is a 32-bit text mode interface built into Windows. The console is also known as the MS-DOS prompt, this is the window that opens with the C:\> prompt. This is where you can type in commands such DIR, COPY, REN. It looks, feels and acts just the like the old DOS that we all remember did. The commands you type in DIR, COPY, REN, etc. are all now 32-bit Windows console application's and not 16-bit DOS applications. What I am trying to get at is that you do not need to create fancy looking dialogs with buttons and graphics to create 32-bit Windows applications. You can create applications that are not limited to 640K, you can DIM x%(10000000), create a string that's 2 million bytes long, and in 32-bit mode, it runs circles around a comparable DOS program. Our PowerBASIC Console Compiler creates 32-bit console applications, but best yet is that it's syntax is 95% compatible with DOS BASIC syntax. You use statement such as PRINT, INPUT, LOCATE, COLOR, etc. just like the DOS BASIC we all are used to. We have almost all of the commands you are used to but also have added many advanced features to the language to take advantage of the power of Windows. Once you get started you will be amazed at how easy it is to move an existing 16-bit DOS application to 32-bit Windows. The Console compiler also has a complete graphics package built in and the ability to work with USB and networked printers.

    You can read the entire PowerBASIC Console Compiler manual online at http://www.powerbasic.com/support/help/pbcc/index.htm. There is even a section on upgrading from DOS to 32-bit Windows Console programming section at http://www.powerbasic.com/support/he...ng_to_pbcc.htm. I think you will find that moving from DOS to the console is relatively painless and will prepare you if you wish to a future move to GUI programming.

    Here is a small example console program:

    #COMPILE EXE

    FUNCTION PBMAIN () AS LONG

    100 CLS
    110 PRINT "PBCC Example"
    120 PRINT
    130 INPUT "What is your name?", n$
    140 PRINT
    150 PRINT "Hello ";n$
    155 REM Wait for keypress before exiting
    160 n$ = INKEY$
    170 IF n$="" THEN 160
    180 END

    END FUNCTION

    I am sure there are only 3 statements that you do not understand in the above code:
    #COMPILE EXE says that we will be creating an EXE file and not a DLL or other compiled file type.

    The FUNCTION PBMAIN () AS LONG is the entry point for the program. When Windows runs a program it will look for this function as the starting point to run the program as compared to DOS which starts running that program at the first line.

    The END FUNCTION says that this is the end of the PBMAIN (entry point) function and when a program reaches the end of the entry point function the program stops running. We did not really need the line 180 END statement as the program would stop running when it reaches the END FUNCTION statement.

    Also line numbers are not necessary but I used them anyways.

    Look at the console help file, the console examples in the download section of our website, and the console programing forums and see just how familiar you are with the language.

    Leave a comment:


  • Giuseppe Belziti
    started a topic PB Dos on 64 bit

    PB Dos on 64 bit

    Hi,
    How I do to run a PB Dos application on 64 bit SO.
    I have feel of WOW64.EXE, but where I find it?

    Thanks
    Giuseppe
Working...
X