rfutscher@pbs.org (12/07/90)
> In article <2480@sixhub.UUCP> ibmbin-request@crdgw1.crd.ge.com writes: >>Checksum: 3145060683 (Verify with "brik -cv") >>Posting-number: Volume 09, Issue 051 >>Submitted-by: mimsy!gargoyle.uchicago.edu!ddsw1!andyross@uunet.uu.net >>Archive-name: infop135/part01 >> >> infoplus produces tons of info on your system hardware configuration. > : > I tried Infoplus 135, it worked fine until page 9 then it hung my system. Running under windows I had to terminate the program. Running under DOS I had to reboot. On page nine I had a collum of info on the left side of the display and one entry with no data on the right side. Any one else having problems?
Unknown (12/07/90)
In article <1990Dec6.112656.10927@pbs.org>, rfutscher@pbs.org says: > > >> In article <2480@sixhub.UUCP> ibmbin-request@crdgw1.crd.ge.com writes: >>>Checksum: 3145060683 (Verify with "brik -cv") >>>Posting-number: Volume 09, Issue 051 >>>Submitted-by: mimsy!gargoyle.uchicago.edu!ddsw1!andyross@uunet.uu.net >>>Archive-name: infop135/part01 >>> >>> infoplus produces tons of info on your system hardware configuration. >> : >> > I tried Infoplus 135, it worked fine until page 9 then it hung >my system. Running under windows I had to terminate the program. >Running under DOS I had to reboot. On page nine I had a collum of >info on the left side of the display and one entry with no data >on the right side. Any one else having problems? As a matter of fact... The program tried to access my B: drive and immediately hung (there wasn't a disk in the system). When I put a disk in, it ignored it. I couldn't even three-finger-salute. I had to turn off the computer. Carl Schelin tcs@mailer.jhuapl.edu
jag@PacBell.COM (Jim Goncher) (12/08/90)
In article <1990Dec6.112656.10927@pbs.org> rfutscher@pbs.org writes: > I tried Infoplus 135, it worked fine until page 9 then it hung >my system. Running under windows I had to terminate the program. >Running under DOS I had to reboot. On page nine I had a collum of >info on the left side of the display and one entry with no data >on the right side. Any one else having problems? I am experiencing exactly the same symptoms. I can get to the pages after 9 using ENTER and they all work fine. -- Jim Goncher 415/823-0663 {bellcore,sun,ames,pyramid}!pacbell!jag
system@infopls.UUCP (SYSOP) (12/10/90)
Unknown writes: > In article <1990Dec6.112656.10927@pbs.org>, rfutscher@pbs.org says: > > As a matter of fact... The program tried to access my B: drive and > immediately hung (there wasn't a disk in the system). When I put a > disk in, it ignored it. I couldn't even three-finger-salute. I had to > turn off the computer. > > Carl Schelin > tcs@mailer.jhuapl.edu I was finally able to duplicate and track down the above bug. Turns out that it was code I used to determine if large partitions were available if DOS 3.3-3.99 was detected. I need to get the address of the driver for the particular drive, and then check a bit in it. Problem is, DOS's INT 25h uses 0=A, 1=B, etc.. The call to get the driver address uses 0=default, 1=A, etc.. One of those DUUHH type of errors. There's another DUHH error fixed in Infoplus 1.41, which should be out by the time you read this. (To check if I've really fixed the problem, try to go to a D: partition [if you don't have a D:, try doing something like SUBST D: C:\TEST, and make D: your default.] If it works, then that is the problem.) It seems as if some computers will time themselves out (may the so-called 'hangups' might time out after a couple minutes?) Others may just sit there forever, especially if B: is a 360K or 720K. --------------- Andrew Rossmann andyross@infopls.UUCP or ..!uunet!ddsw1!infopls!system Infoplus Support BBS +1 708 537 0247, 1200/2400, 24 hours
rusbasra@mentor.cc.purdue.edu (Bob Rusbasan) (12/10/90)
In article <77197@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >mlord@bwdls58.bnr.ca (Mark Lord) <5068@bwdls58.UUCP> : >| Here's a suggestion you may find convenient: >| >| Link the BGI files into the executable, so that the clock program becomes >| a fully self-contained module. This would make it easier for me to use, >| and perhaps some others as well. The Borland manuals explain how to do this, >| using BGIOBJ [corrected] to create cga.obj and egavga.obj, which are then >| linked along with the program into one happy executable. >Having been informed that I can link both .BGI files in, (and since I hope >to have a personal interest soon :-) I'll do that. Thanks, Timo. >The manual wasn't *that* clear... And be aware that it's not THAT easy. You may want to use the /f option of BGIOBJ, and you also have to "register" the modules within the C program. It does NOT work if you just like in the object files. >OS!" :-). Evidently this idea isn't very exciting to everybody else, >who keep telling me that I don't have to share the code, I can put a >separate copy into every program.... Is it that I'm hoarding disk space >more tightly than others, or does no one use enough of these graphics >files for it to matter? Or what? I personally use the BGI files and name the path when I'm developing something, but I link them it when I finish the program. For one thing, it looks more professional. For another, you can't count on everyone having the same directory for them, and people like to run things from directories that they're not currently, so the BGI files won't work well in that case. When people get the program, I think most of them would rather get fewer files too. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- / Bob Rusbasan | "So many pitchforks, so little hay." \ / bob@en.ecn.purdue.edu | - Old MacDonald in hell \ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
mcastle@mcs213d.cs.umr.edu (Mike Castle (Nexus)) (12/10/90)
How much does linking in ALL the *.bgi files into the .exe affect the size?
Which would be a better deal: one .exe file with all the *.bgi files, or
multiple *.exe files, each with a different (and hard coded calls to) *.bgi
file? The single *.exe file would be more convenient, but possibly very
large. Separate *.exe files would be more system dependent, but once the
user installed just the single *.exe he needs, then he'll save some disk
space. Essentially, it's a trade off between ease of use and storage space.
Maybe a package with both types, and letting the user decide??
Just wondering,
Mike
--
Mike Castle (Nexus) S087891@UMRVMA.UMR.EDU (preferred) | ERROR: Invalid
mcastle@mcs213k.cs.umr.edu (unix mail-YEACH!)| command 'HELP'
Life is like a clock: You can work constantly, and be right | try 'HELP'
all the time, or not work at all, and be right twice a day. |tcs@mailer.jhuapl.edu (12/10/90)
In article <1821@umriscc.isc.umr.edu>, mcastle@mcs213d.cs.umr.edu (Mike Castle (Nexus)) says: > >How much does linking in ALL the *.bgi files into the .exe affect the size? >Which would be a better deal: one .exe file with all the *.bgi files, or >multiple *.exe files, each with a different (and hard coded calls to) *.bgi >file? The single *.exe file would be more convenient, but possibly very >large. Separate *.exe files would be more system dependent, but once the >user installed just the single *.exe he needs, then he'll save some disk >space. Essentially, it's a trade off between ease of use and storage space. > >Maybe a package with both types, and letting the user decide?? > >Just wondering, >Mike >-- >Mike Castle (Nexus) S087891@UMRVMA.UMR.EDU (preferred) | ERROR: Invalid > mcastle@mcs213k.cs.umr.edu (unix mail-YEACH!)| command 'HELP' >Life is like a clock: You can work constantly, and be right | try 'HELP' >all the time, or not work at all, and be right twice a day. | There are 15 or so .BGI and .CHR files and each take from 4k to 6k. This would add about 80k to each .exe file. (Of course you don't HAVE to add the AT&T 6300 driver or whatever the video driver is called. :) But the EGAVGA.obj and the CGA.obj files add about 10k to the end program. If you use any .CHR files, it adds another 4k. These files changed one of my programs from a small model to a medium model (causing me to wait until the registered version of CXL arrived before I could ship it). Personally I don't like to ship more than just the .exe and .doc files. Then you can run it from anywhere. Carl Schelin tcs@mailer.jhuapl.edu
dslg0849@uxa.cso.uiuc.edu (Daniel S. Lewart) (12/11/90)
mcastle@mcs213d.cs.umr.edu (Mike Castle (Nexus)) writes: > How much does linking in ALL the *.bgi files into the .exe affect the size? > Which would be a better deal: one .exe file with all the *.bgi files, or > multiple *.exe files, each with a different (and hard coded calls to) *.bgi > file? The single *.exe file would be more convenient, but possibly very > large. Separate *.exe files would be more system dependent, but once the > user installed just the single *.exe he needs, then he'll save some disk > space. Essentially, it's a trade off between ease of use and storage space. > > Maybe a package with both types, and letting the user decide?? With Turbo Pascal, there is also the option of registering and overlaying the .BGI and .CHR files. Overlaying will create a .OVR file in addition to the .EXE file. Daniel Lewart d-lewart@uiuc.edu
berger@iboga (Mike Berger) (12/14/90)
rfutscher@pbs.org writes: > I tried Infoplus 135, it worked fine until page 9 then it hung >my system. Running under windows I had to terminate the program. >Running under DOS I had to reboot. On page nine I had a collum of >info on the left side of the display and one entry with no data >on the right side. Any one else having problems? *---- Yes - the very same problem. That's scary in a program that's supposed to figure out what environment it's running under. I have an 80386, 8 MB RAM, AMI Bios. -- Mike Berger Department of Statistics, University of Illinois AT&TNET 217-244-6067 Internet berger@atropa.stat.uiuc.edu
ken@gtenmc.UUCP (Ken Swapp) (12/18/90)
rfutscher@pbs.org wrote: ... about problems with Infoplus 1.35 on page 9. berger@iboga (Mike Berger) wrote: > >Yes - the very same problem. That's scary in a program that's supposed >to figure out what environment it's running under. I have an 80386, >8 MB RAM, AMI Bios. I have successfully run all pages of Infoplus 1.35 on several 386 AST computers w/ AST BIOS, containing up to 3 MB of memory. -Ken-- --------------------------------------------------------- Ken Swapp / ken@gtenmc.UUCP "Be careful that the light you find at the end of the tunnel isn't the flashlight you dropped on your way in."
berger@atropa (Dire Wolf) (12/19/90)
Infoplus 1.40 did solve the problem - it works correctly on my computer now. -- Mike Berger Department of Statistics, University of Illinois AT&TNET 217-244-6067 Internet berger@atropa.stat.uiuc.edu