Announcement

**Peter Lameijn** · 6 Jun 2007, 09:04 AM

You can keep using lprint. Should work with all Win-OS. Only thing is that printer must be also set up for command (DOS) windows.
That's not always done properly. Can be done with "NET USE ..." or printer setup

------------------
Regards,
Peter

**Paul D. Elliott** · 6 Jun 2007, 09:19 AM

Check out a program called DOSPrint. You buy it once and can
distribute the registered program with your software for free.
Only $99 if you order on the web now ( I was just at the site ).
This way you can use normal printer control codes & it will
handle printing to any printer connected to Windows. The
Windows-only printers can NOT be printed to from standard DOS
programs or by merely copying the text-output to LPT1.

The web site is www.DOSPrint.com

------------------

**Peter Lameijn** · 6 Jun 2007, 10:02 AM

The Windows-only printers can NOT be printed to from standard DOS programs

With LPRINT you CAN if printing from a DOS window is enabled...

------------------
Regards,
Peter

**Paul D. Elliott** · 6 Jun 2007, 11:10 AM

Peter,

You've peeked my curiosity.

Please explain how exactly?

------------------

**Michael Mattias** · 6 Jun 2007, 11:20 AM

>You've peeked my curiosity

This won't compile...can you help?

Code:

  StringVar = PIQUE(address, byte_count)

**Mel Bishop** · 6 Jun 2007, 11:31 AM

As an additional option and you want to keep it in PB/DOS,
reroute the printer output to a disk file then shell out and
bring the file up in Word/Notepad or other word processor.

------------------

**Paul D. Elliott** · 6 Jun 2007, 11:36 AM

Michael,

Should it have been "piqued" ? Sorry but I'm not running
a spell-checker in a programming forum. generally I just
write it as it sounds.

------------------

But I'm still curious as to where I enable this option.

[This message has been edited by Paul D. Elliott (edited June 06, 2007).]

**Mike Doty** · 6 Jun 2007, 12:43 PM

I create files with DOS then shell to them using ddoc.
It could also be done using XPRINT. To eliminate the
shell a background print monitor can also be used that
prints whenever it finds an output file created by
the dos program.

------------------

**Peter Lameijn** · 6 Jun 2007, 02:02 PM

But I'm still curious as to where I enable this option.

Set the printer to shared on the printers properties tab (make sure the share name complies to 8.3 naming convention)
You can also use NET USE LPT1: \\MyComputerName\MyPrinterName inside a command (dos) window

------------------
Regards,
Peter

**Tom Tallardy** · 6 Jun 2007, 03:08 PM

Fred -

not sure how big your program is, but I can attest to the fact that rolling PBDOS over into PBCC is not difficult, at all.

mebets you could have the PBDOS app running in PBCC within an hour, mebbe seconds.

the XPRINT functions give you ways lots more control over paper output way lots easier. pick your printer, pick a font, pick a font size, underline, bold, italic, whatever.

on the "down" side,
(which, given the huge functional increases is very tiny in relation to gain, depending on how complex your printing is)
XPRINT can be a bit more work in "placing" text where you want it.

example: there is no XPRINT TAB

but in the end you can control virtually every spec of ink on the paper using PB functions that won't stop your still beating DOS heart.

if you've already got PBCC with XPRINT, I wouldn't waste a penny or a second on any "solutions" that leaves you still hampered by things you can do only on a dot matrix....
go fer'the gold.

------------------

**Paul D. Elliott** · 6 Jun 2007, 03:19 PM

Please, Sir, may I have some more?

I'm running W2k with a LJ 1018 printer. I've got it shared as
LJUSB. I can copy text to it but seeing as it doesn't go thru
the Windows driver then the printer can't understand it ( or at
least as near as I can tell ... just blinks the lights and sits
there ). I've even copied a form-feed to it but no change.

I see no option for "DOS printing" to be enabled.

What am I missing?

------------------

This method does work well if the printer is a DOS-compatible
printer. I used this method for over 6 years in support of a
system that needed to print to dot-matrix printers connected
to a network. The OS ranged from plain DOS to W2k and we never
had to install those printers on any system ( except maybe the
servers but we dumped output straight to the print queues ...
never running thru any driver ).

[This message has been edited by Paul D. Elliott (edited June 06, 2007).]

**Joe Byrne** · 6 Jun 2007, 05:14 PM

I've written a nice DOS program that I want to offer for sale on a web site I'll soon be constructing.

Please, this is a serious question, and not meant to sound "bashing", etc.

I am extremely curious to know what type of customer or what type of application would someone still buy that is DOS based? I can't for the life of me think of a single scenario where DOS is the preferred, or even accepted, application OS other than perhaps some highly specific embedded devices.

------------------
* Americans: Time for the right party
-------------------------
Read my Blog

**Buck Huffman** · 7 Jun 2007, 12:54 AM

DOS applications aren't easily distinguishable from console applications
in their outward appearance. So, to many users, it's a question of getting
the job done, if a DOS app gets the job done then why not use it? An added
advantage with DOS is that a well written app can be run on many platforms
such as all versions of windows, most macs, multiple *nix variants... by
means of VM's and emulators. That kind of portability is very hard to
achieve by any other means.

Few people understand why anyone would do things differently from them, I
guess it's just human nature. To a programmer, the advantages of 32-bit
code may seem too good to pass up. but to the end user the extra work that
the programmer has to do to write 16-bit code doesn't really mean a lot.
I have frequently answered questions such as: what is an operating system?
what does an OS do? How do I run my OS? What's the difference between 16-
bit and 32 bit? What is a bit?... It's not because people are dumb, but
because it doesn't really affect them in any way that they can personally
see. generally, users who express a preference have, probably, either done
some programming themselves(~3 or 4%), or have been told that 32-bit is
better by someone else and don't really have a preference of their own(the
rest).

I guess what it boils down to is that there are still a few users left who
have not formed a prejudice against dos apps yet. but their numbers are
dwindling as anti-DOS sentiment becomes more and more prevalent. Nice to
see that Micro$haft hasn't given up on it. I've noticed that windows xp
and vista include at least two versions of DOS. So the rumors of DOS's
death have been exaggerated a little, only time will tell by how much.

------------------

**Joe Byrne** · 7 Jun 2007, 01:41 AM

Buck,

Thanks for the comments. I see your point and have to agree mostly.

I guess I've been a bit sequestered in the business application market. I couldn't sell a console app if my life depended on it. My customer base is used to the GUI and anything short of a polished interface makes them think the app is inferior and worthless.

As I thought about this though, I do recall seeing a couple of POS systems that were console based, and POS is a large vertical. It seems to me though, that PB/CC is so close to the old DOS code that it would usually be preferred over a true DOS program, thus allowing the programmer all the advantages Windows has to offer. Of course, portability is a big issue in some vertical markets so it would make sense to use something with a closer common denominator.

All-in-all though, its nice to know that some people can still make a buck with DOS apps. I have very fond memories of PB1,2,3, and 3.5. I still remember the rush I got when my first TSR worked as planned...then I never used the feature again

Sure was fun though.

------------------
* Americans: Time for the right party
-------------------------
Read my Blog

**Chris Holbrook** · 7 Jun 2007, 02:57 AM

I had a similar problem recently, a legacy application (not PB) which output to the printer on stdout. The application had to work in a DOS or XP environment. Changed the application at a low level to create a file from the printed output and to run a user-specified program (different in XP and DOS) on completion of each report, very little new code required . The idea was to use a 3rd party utility to do the actual printing in XP, but I ended up coding a PBWin application which enabled the reports to be previewed when run in an XP environment. This application uses only non-PS fonts and adjusts the font and orientation according to the report width. It won't work properly if you use PS fonts, but of course the legacy application doesn't. This feature saved the user a lot of time and paper!

------------------

**Fred Lampart** · 7 Jun 2007, 06:40 AM

Originally posted by Peter Lameijn:
You can keep using lprint. Should work with all Win-OS. Only thing is that printer must be also set up for command (DOS) windows.
That's not always done properly. Can be done with "NET USE ..." or printer setup

Peter,
Customers that may wish to use my program may or may not wish to go through the printer setup you describe especially if can be difficult.
I'd like to look at options that are more user friendly... thanks for the reply though.
Fred

------------------

**Michael Mattias** · 7 Jun 2007, 07:54 AM

...My program isn't that well suited to a Windows environment (and I'm not Windows programmer) so migrating the code to a Windows environment isn't a direction I wish to go....

...Customers that may wish to use my program may or may not wish to go through the printer setup you describe especially if can be difficult. I'd like to look at options that are more user friendly

The good news is, you understand your challenge.

The bad news is, you now understand what is required to make your MS-DOS software work on non-MS-DOS systems.

Your best bet may be to either write yourself, contract for or purchase some kind of Windows-based utility which you can SHELL from your MS-DOS program....

Code:

    OPEN printerfilename for output...
    PRINT #file, printline
    ...
    CLOSE #file
    SHELL  "theutility.exe " + printerfile [ + optionstring]
    ' option string might be "font=Arial,paper=8x11,printer=HP 870C,more options"
    ' or maybe the name of a configuration (INI) file

(I thought someone here had something like this?).

MCM

**Chris Holbrook** · 7 Jun 2007, 08:30 AM

Originally posted by Fred Lampart:
My program isn't that well suited to a Windows environment

As a matter of interest, will a PB DOS executable run OK as an XP console application?

------------------

**Mike Doty** · 7 Jun 2007, 08:59 AM

Yes. Screen size issues are the only problem I've seen.
Shelling may cause the screen to become minimized.
Some DELL laptops refuse to allow full screen mode.
Some issues corrected by using a WIDTH 80,25.

------------------

Announcement

Print from DOS Advice

Print from DOS Advice

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment