I've been playing with printing options trying to see if I can print direct to LPT1 and bypass printing through notepad.
In the past to enable printing from a legacy app to a USB or network printer I've always shared the printer and done a NET USE LPT1. Then the legacy app can write to LPT1 as if it was a physical port and never know the difference.
However, I'm having trouble doing the same in PC-BASIC. If I use --lpt1=parport:lpt1 I always get an exception on the WIDTH statement:
EXCEPTION
49 WIDTH "lpt1:",80
pcbasic.run:66, run_once
None
pcbasic.statements:132, parse_statement
None
pcbasic.statements:2483, exec_width
None
AttributeError: 'NoneType' object has no attribute 'set_width'
The documentation for --lpt1 suggests this should be possible, but I can't seem to get it to work. I'm running on Win10-64 with version 15.08.9.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, it looks like the connection to the port has not been initialised somehow. Could you run pcbasic with --logfile=log.txt to see if any messages appear in the log file?
Also, could you please run pcbasic --debug -v and post the result here - it sould give some more detail on the setup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LPT1 is mapped to a shared printer with NET USE and I confimed I can print a text file from the command line with:
print /d:lpt1 test.txt
Here's the command line from the shortcut I've setup:
"C:\Program Files (x86)\PC-BASIC\pcbasic.exe" kfmenu.bas -s=890 -f=9 --map-drives --lpt1=parport:lpt1 --print-trigger=page --dimensions=800,500 --logfile=c:\temp\log.txt
The working folder is set to the folder containing kfmenu.bas.
Here's the log:
WARNING: Parallel module not found. Parallel port communication not available.
ERROR: Traceback (most recent call last):
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.run", line 66, in run_once
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.statements", line 132, in parse_statement
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.statements", line 2480, in exec_width
AttributeError: 'NoneType' object has no attribute 'set_width'
PC-BASIC doesn't launch when I include -v and doesn't seem to echo anything to the console. But when I just have --debug it launches and displays:
PC-BASIC 15.08.9 [DEBUG mode]
(C) Copyright 2013--2016 Rob Hagemans.
60300 Bytes free
Ok
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1 - It looks like I haven't included the parallel module with the Windows package, which is needed to access the LPT1: port. If I build a version including it and post it here - would you be able to check if it works? There may be issues as that module appears to be discontinued by its developer and moreover I don't currently have a parallel port myself to test it.
2 - All this assumes you're wrining to a physical parallel port and I don't actually know whether that really is the interface NET USE LPT1 simulates. It may well be the case that it's more like a character device/named pipe sort of thing, in which case it might be possible that --lpt1=FILE:LPT1: does the job- it would result in raw bytes being sent to LPT1, which sounds like what you describe you are successfully doing in other programs. But I’m not sure of this - I'm not familiar with the print command on Windows. Would something like copy myfile.txt LPT1: work in your setup? If so, then the FILE approach should work as well.
As an aside: the reason you're not getting console messages is that you're using the GUI binary pcbasic.exe to run from the command line - nothing wrong with that in pricnciple but if you use the console binary pcbasic.com you should be able to see the warnings and the output of the -v --debug option. The latter option does indeed not start PC-BASIC but if run with the console binary it should print a version string and the versions of the modules included to the console. Alternatively you could run with -v --debug --logfile=c:\temp\log.txt to output the version and module information to the log file.
Cheers
Rob
Last edit: Rob Hagemans 2016-06-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, the option in (2) should probably be --lpt1=FILE:LPT1 (without trailing colon) and the other command line may have to be type myfile.txt > LPT1 or copy /b myfile.txt LPT1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, I didn't even notice pc-basic.com. Here's the output:
pcbasic.com --debug -v
1
5P.L0A8T.F9O
RM
os: Windows Intel64 Family 6 Model 58 Stepping 9, GenuineIntel 6.2.9200
python: 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] 32bit WindowsPE
MODULES
numpy: 1.8.0
available
pygame: 1.9.2pre
curses: --
pexpect: 2.3
serial: 2.7
parallel: --
Sure, I'd be happy to test a build with the parrallel module included. If you're running Windows and have a local USB printer, you can just share it and then NET USE LPT1 \mypc\myprinter to try it yourself. Or obvioulsy do the same with a printer shared from another machine on your network.
And yes, copy /b myfile.txt LPT1 works, but unfortunately, --lpt1=FILE:LPT1 doesn't. I tired it with and without the trailing colon just to be sure.
BTW, I think the print /d:lpt1 myfile.txt does the same thing as copy /b myfile.txt LPT1. The only difference is that print.exe is a Win32 executable.
As far as saving output to an actual text file and then copying to lpt1, how do I accomplish that with PC-BASIC? I guess I'd have to use the default --lpt1=printer: and change the print command in the .txt file association to copy to lpt1 instead of using notepad to print? There no way to tell PC-BASIC to run some command to print is there? That would probably be a nice option...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, interesting output - it seems the standard-output and standard-error get mixed up leading to that odd mix of letters (which should really be 15.08.9 and PLATFORM. Something else to fix, there, at some point.
The more I look at it the more I am convinced that parallel and PARPORT: are not what you need - a local USB printer really is not a parallel port, and parallel is meant to enable things like setting a particular output or status pin on a Centronics/DB25 port like they were used in the MS-DOS era to connect printers.
Reading up on NET USE it looks much more like NET USE LPT1 results in a special filename/pipe/character device kind of thing connected to the print spooler, that just happens to have the same name as the MS-DOS parallel device. FILE: really ought to be able to handle that, especially since you can simply copy a text file straight to LPT1.
The question thus is why FILE does not work. I'll have to experiment with that. The errors you post are not at all what I would expect so something strange is going on here. I'll need to investigate this..
I got the impression that print.exe actually used Notepad to print text files, but I may be wrong. PC-BASIC uses the printto shell verb on Windows, which does seem to route the file through Notepad (or presumably whatever program is set to handle text files). I thought this was the standard approach for Windows, but if print.exe is different I'll have to see which approach is best. If it really does exactly the same as copy /b then that kind of thing should end up being supported through FILE.
As for sending output to files - you should be able to use --lpt1=FILE:myprint.txt to send all prints to that text file. Does that work? If not, please post the error message if any - it may be related to the issue with FILE:LPT1. Similarly, --lpt1=STDIO would send the print to standard output (the console). You could then use pipes and redirection on the Windows command line to send it to a command of your choice.
Hope this helps,
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Print.exe is not related to printto shell verb. printto uses whatever program you've associated with the txt file extension (notepad by default). Print.exe just sends the file to the specified port umolested, bypassing the windows printer driver, like redirecting a file to LPT1.
Yeah, sending output to a file is no problem, it's just getting it copied to the printer in a way that is good for the user that is the challenge. I think that would pretty much mean creating a batch file that would launch PC-BAISC, wait for it to exit and then copy to the printer, which I don't think would be acceptable for the users.
If this isn't something that you are otherwise interested in solving, then don't knock yourself out. Like you said, you're doing this for fun. I've been messing around with vDOS and think I can put together a good solution with that. But if it's something you're interested in anyway, then I'm glad to help out if you need me to test something or do any other diagnostics.
Last edit: Mitch McHenry 2016-06-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a look at the code and I think I should be able to make printing to a mapped LPT1 work easily with the --lpt1=FILE:LPT1; the fact that it doesn't now is just a bug. As is the fact that it crashes if you try a parallel port and it fails - it should just give a console warning and maybe a Device Unavailable error. Once these things are solved you should be able to use that option to print to a mapped printer at LPT1 and probably at a network share - anything that would work with copy /b should in principle work. There will likely be additional issues relating to character encodings, but let's take one thing at a time.
I'll also update the documentation to make it clear this is how you need to do things if you want to send raw bytes to a NET USE mapped printer, that PARPORT: is only for controlling real parallel ports and that PRINTER sends things through the OS's printer driver.
I think after doing that PC-BASIC should be able to print directly, the way you prefer it. I'm reluctant to add functionality like outputting to user-defined print commands which would add further complexity - the number of things that can go wrong grows with the number of permutations of options and getting the options we have to work as expected is clearly already a challenge :). It seems that this sort of thing is supported by the OS - I appreciate that in Windows things like redirection and pipes are a bit more difficult and unpredicatble than in Unix but I don't feel I should be reproducing that kind of OS functionality too much...
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool, glad it's not a big deal. Let me know if you want me to test anything.
Custom print commands would be nice, but if you get the direct to LPT working, then there's a lot less need for it. FILE:LPT1 and PRINTER: should cover most cases.
If you wanted to add any more flexibility, rather than custom print commands, enhancing the FILE:myfile.txt option to close the file when you're not writing to it would be nice. That would let it work with tools like WinPrint that monitor an output file and after an interval of no modification (usually like 500ms), will rename, print and delete the file. Those tools also handle a lot of DOS printing concerns like font selection, code page translation, etc.
Last edit: Mitch McHenry 2016-06-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "[CLOSED] Bug reports" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I've been playing with printing options trying to see if I can print direct to LPT1 and bypass printing through notepad.
In the past to enable printing from a legacy app to a USB or network printer I've always shared the printer and done a NET USE LPT1. Then the legacy app can write to LPT1 as if it was a physical port and never know the difference.
However, I'm having trouble doing the same in PC-BASIC. If I use --lpt1=parport:lpt1 I always get an exception on the WIDTH statement:
EXCEPTION
49 WIDTH "lpt1:",80
pcbasic.run:66, run_once
None
pcbasic.statements:132, parse_statement
None
pcbasic.statements:2483, exec_width
None
AttributeError: 'NoneType' object has no attribute 'set_width'
The documentation for --lpt1 suggests this should be possible, but I can't seem to get it to work. I'm running on Win10-64 with version 15.08.9.
Hi, it looks like the connection to the port has not been initialised somehow. Could you run pcbasic with
--logfile=log.txt
to see if any messages appear in the log file?Also, could you please run
pcbasic --debug -v
and post the result here - it sould give some more detail on the setup.LPT1 is mapped to a shared printer with NET USE and I confimed I can print a text file from the command line with:
print /d:lpt1 test.txt
Here's the command line from the shortcut I've setup:
"C:\Program Files (x86)\PC-BASIC\pcbasic.exe" kfmenu.bas -s=890 -f=9 --map-drives --lpt1=parport:lpt1 --print-trigger=page --dimensions=800,500 --logfile=c:\temp\log.txt
The working folder is set to the folder containing kfmenu.bas.
Here's the log:
WARNING: Parallel module not found. Parallel port communication not available.
ERROR: Traceback (most recent call last):
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.run", line 66, in run_once
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.statements", line 132, in parse_statement
File "E:\branch1508\packaging\windows\build\installer\out00-PYZ.pyz\pcbasic.statements", line 2480, in exec_width
AttributeError: 'NoneType' object has no attribute 'set_width'
PC-BASIC doesn't launch when I include -v and doesn't seem to echo anything to the console. But when I just have --debug it launches and displays:
PC-BASIC 15.08.9 [DEBUG mode]
(C) Copyright 2013--2016 Rob Hagemans.
60300 Bytes free
Ok
Hi Mitch, thanks for the extra info!
1 - It looks like I haven't included the
parallel
module with the Windows package, which is needed to access theLPT1:
port. If I build a version including it and post it here - would you be able to check if it works? There may be issues as that module appears to be discontinued by its developer and moreover I don't currently have a parallel port myself to test it.2 - All this assumes you're wrining to a physical parallel port and I don't actually know whether that really is the interface
NET USE LPT1
simulates. It may well be the case that it's more like a character device/named pipe sort of thing, in which case it might be possible that--lpt1=FILE:LPT1:
does the job- it would result in raw bytes being sent to LPT1, which sounds like what you describe you are successfully doing in other programs. But I’m not sure of this - I'm not familiar with theprint
command on Windows. Would something likecopy myfile.txt LPT1:
work in your setup? If so, then theFILE
approach should work as well.As an aside: the reason you're not getting console messages is that you're using the GUI binary
pcbasic.exe
to run from the command line - nothing wrong with that in pricnciple but if you use the console binarypcbasic.com
you should be able to see the warnings and the output of the-v --debug
option. The latter option does indeed not start PC-BASIC but if run with the console binary it should print a version string and the versions of the modules included to the console. Alternatively you could run with-v --debug --logfile=c:\temp\log.txt
to output the version and module information to the log file.Cheers
Rob
Last edit: Rob Hagemans 2016-06-22
Actually, the option in (2) should probably be
--lpt1=FILE:LPT1
(without trailing colon) and the other command line may have to betype myfile.txt > LPT1
orcopy /b myfile.txt LPT1
.Ah, I didn't even notice pc-basic.com. Here's the output:
Sure, I'd be happy to test a build with the parrallel module included. If you're running Windows and have a local USB printer, you can just share it and then NET USE LPT1 \mypc\myprinter to try it yourself. Or obvioulsy do the same with a printer shared from another machine on your network.
And yes,
copy /b myfile.txt LPT1
works, but unfortunately,--lpt1=FILE:LPT1
doesn't. I tired it with and without the trailing colon just to be sure.BTW, I think the
print /d:lpt1 myfile.txt
does the same thing ascopy /b myfile.txt LPT1
. The only difference is thatprint.exe
is a Win32 executable.As far as saving output to an actual text file and then copying to lpt1, how do I accomplish that with PC-BASIC? I guess I'd have to use the default
--lpt1=printer:
and change the print command in the .txt file association to copy to lpt1 instead of using notepad to print? There no way to tell PC-BASIC to run some command to print is there? That would probably be a nice option...Hm, interesting output - it seems the standard-output and standard-error get mixed up leading to that odd mix of letters (which should really be
15.08.9
andPLATFORM
. Something else to fix, there, at some point.The more I look at it the more I am convinced that
parallel
andPARPORT:
are not what you need - a local USB printer really is not a parallel port, andparallel
is meant to enable things like setting a particular output or status pin on a Centronics/DB25 port like they were used in the MS-DOS era to connect printers.Reading up on
NET USE
it looks much more likeNET USE LPT1
results in a special filename/pipe/character device kind of thing connected to the print spooler, that just happens to have the same name as the MS-DOS parallel device.FILE:
really ought to be able to handle that, especially since you can simply copy a text file straight toLPT1
.The question thus is why
FILE
does not work. I'll have to experiment with that. The errors you post are not at all what I would expect so something strange is going on here. I'll need to investigate this..I got the impression that
print.exe
actually used Notepad to print text files, but I may be wrong. PC-BASIC uses theprintto
shell verb on Windows, which does seem to route the file through Notepad (or presumably whatever program is set to handle text files). I thought this was the standard approach for Windows, but ifprint.exe
is different I'll have to see which approach is best. If it really does exactly the same ascopy /b
then that kind of thing should end up being supported throughFILE
.As for sending output to files - you should be able to use
--lpt1=FILE:myprint.txt
to send all prints to that text file. Does that work? If not, please post the error message if any - it may be related to the issue withFILE:LPT1
. Similarly,--lpt1=STDIO
would send the print to standard output (the console). You could then use pipes and redirection on the Windows command line to send it to a command of your choice.Hope this helps,
Rob
Print.exe is not related to printto shell verb. printto uses whatever program you've associated with the txt file extension (notepad by default). Print.exe just sends the file to the specified port umolested, bypassing the windows printer driver, like redirecting a file to LPT1.
Yeah, sending output to a file is no problem, it's just getting it copied to the printer in a way that is good for the user that is the challenge. I think that would pretty much mean creating a batch file that would launch PC-BAISC, wait for it to exit and then copy to the printer, which I don't think would be acceptable for the users.
If this isn't something that you are otherwise interested in solving, then don't knock yourself out. Like you said, you're doing this for fun. I've been messing around with vDOS and think I can put together a good solution with that. But if it's something you're interested in anyway, then I'm glad to help out if you need me to test something or do any other diagnostics.
Last edit: Mitch McHenry 2016-06-22
Hi Mitch, thanks for that information!
I had a look at the code and I think I should be able to make printing to a mapped
LPT1
work easily with the--lpt1=FILE:LPT1
; the fact that it doesn't now is just a bug. As is the fact that it crashes if you try a parallel port and it fails - it should just give a console warning and maybe aDevice Unavailable
error. Once these things are solved you should be able to use that option to print to a mapped printer atLPT1
and probably at a network share - anything that would work withcopy /b
should in principle work. There will likely be additional issues relating to character encodings, but let's take one thing at a time.I'll also update the documentation to make it clear this is how you need to do things if you want to send raw bytes to a
NET USE
mapped printer, thatPARPORT:
is only for controlling real parallel ports and thatPRINTER
sends things through the OS's printer driver.I think after doing that PC-BASIC should be able to print directly, the way you prefer it. I'm reluctant to add functionality like outputting to user-defined print commands which would add further complexity - the number of things that can go wrong grows with the number of permutations of options and getting the options we have to work as expected is clearly already a challenge :). It seems that this sort of thing is supported by the OS - I appreciate that in Windows things like redirection and pipes are a bit more difficult and unpredicatble than in Unix but I don't feel I should be reproducing that kind of OS functionality too much...
Rob
Cool, glad it's not a big deal. Let me know if you want me to test anything.
Custom print commands would be nice, but if you get the direct to LPT working, then there's a lot less need for it.
FILE:LPT1
andPRINTER:
should cover most cases.If you wanted to add any more flexibility, rather than custom print commands, enhancing the
FILE:myfile.txt
option to close the file when you're not writing to it would be nice. That would let it work with tools like WinPrint that monitor an output file and after an interval of no modification (usually like 500ms), will rename, print and delete the file. Those tools also handle a lot of DOS printing concerns like font selection, code page translation, etc.Last edit: Mitch McHenry 2016-06-23