DOS ain't dead - FlWriter version 1.1 available

georgpotthast

Germany,
05.05.2012, 13:32
(edited by georgpotthast, 05.05.2012, 14:52)

FlWriter version 1.1 available (Announce)

I uploaded version 1.1 of FlWriter. You are welcome to take a look at it. ;-)

Download FlWriter

Since version 1.0 was regarded as too big I now have split FlWriter into a basic package and an extension package to reduce the download size. The basic package is 3.6 MB and the extension package 7.2 MB. I also made FlWriter use its own routine to generate postscript files so I could omit HTMLDOC with its fonts. That reduced the package size by 5.8 MB. Also the basic package contains only a few fonts while the rest is in the extension package.

The major enhancment is that the new version now supports to insert images in the text and print those in color.

The code has been changed so long file support is no longer needed, FlWriter will just use short file names.

There is a virtual keyboard now to enter symbols plus characters of different languages. For Arabic characters I enabled optional right to left text orientation.

The new postscript routine not only allows to print images but improves WYSIWYG regarding TABs and page breaks too.

Finally I added top/bottom margins to the page setup and removed the flicker that appeared when moving the cursor.

Further details are in the updated readme.htm file.

Georg

[image]

Arjay 05.05.2012, 15:36 @ georgpotthast	FlWriter version 1.1 available Post reply
	> I uploaded version 1.1 of FlWriter. You are welcome to take a look at it. > Done - excellent news. Still reviewing. > Further details are in the updated readme.htm file. One constructive comment, any chance of a basic readme.txt file in addition to readme.htm ?

georgpotthast Germany, 05.05.2012, 16:30 @ Arjay	FlWriter version 1.1 available Post reply
	> > I uploaded version 1.1 of FlWriter. You are welcome to take a look at > it. > > > Done - excellent news. Still reviewing. > > > > Further details are in the updated readme.htm file. > One constructive comment, any chance of a basic readme.txt file in addition > to readme.htm ? You could open readme.htm in any browser, e.g. the one you used to post your message. Georg

Arjay

05.05.2012, 17:51

@ georgpotthast

FlWriter version 1.1 available

Post reply

> You could open readme.htm in any browser, e.g. the one you used to post
> your message.
Indeed I could, however I wasn't thinking of myself when I made the observation but for people who may have had FlWriter copied for them by others via sneaker.net, e.g. remote parts of Africa etc. or people who have copied FlWriter to a slow non-network connected PC unzipped and then gone to RTF.

Still thank you for taking on the feedback re download size. Downloaded easily over this slowish link and readme.htm opened fine with FlWriter after install:)

Wengier

05.05.2012, 22:40
(edited by Wengier, 05.05.2012, 23:06)

@ georgpotthast

FlWriter version 1.1 available

Post reply

> I uploaded version 1.1 of FlWriter. You are welcome to take a look at it.
> ;-)
>
> Download
> FlWriter
>
> Since version 1.0 was regarded as too big I now have split FlWriter into a
> basic package and an extension package to reduce the download size. The
> basic package is 3.6 MB and the extension package 7.2 MB. I also made
> FlWriter use its own routine to generate postscript files so I could omit
> HTMLDOC with its fonts. That reduced the package size by 5.8 MB. Also the
> basic package contains only a few fonts while the rest is in the extension
> package.

Thanks for the downloads (both parts). Have not been able to generate PCL print files (the PRN file is short), but the postscript part is an excellent work -- I have tried to print the README file with it and it works nicely when printing as PostScript to my Brother laser printer. Thanks again.

Doug

06.05.2012, 20:34

@ georgpotthast

FlWriter version 1.1 available

Post reply

Georg -

V1.1 is looking/working better! However, i'm not able to create PDF files. Even with just a few lines of text, the program displays the following error message:
The print file could not be created!
I unzipped both the basic and extension packages to their default directory on my D: drive, which created D:\FLWRITER\ and the respective subdirs.

Some other feedback (unrelated to above):

o The Esc key is darned EVIL!!! :-| When used to escape from a menu item, it terminates FlWriter... back to command line... unexpected... ouch....

o Dialog boxes show path separaters as forward slashes (rather than back slashes) -- cosmetic... but unix-y, not DOS-ish! (I always find this kind of startling/confusing whenever i see it.) But again, *greatly* appreciate the conversion to short file names.

o File > Save File removes blank lines between paragraphs. (Because i didn't put a space character there?) A little quirky to have to do that.

As always, many thanks for all the work....

- Doug B.

georgpotthast

Germany,
07.05.2012, 18:20
(edited by georgpotthast, 07.05.2012, 21:26)

@ Doug

FlWriter version 1.1 available

Post reply

> Georg -
>
> V1.1 is looking/working better! However, i'm not able to create PDF files.
> Even with just a few lines of text, the program displays the following
> error message:
> > The print file could not be created! >
> I unzipped both the basic and extension packages to their default directory
> on my D: drive, which created D:\FLWRITER\ and the respective subdirs.
>
> Some other feedback (unrelated to above):
>
> o The Esc key is darned EVIL!!! :-| When used to escape from a menu item,
> it terminates FlWriter... back to command line... unexpected... ouch....
>
>
> o Dialog boxes show path separaters as forward slashes (rather than back
> slashes) -- cosmetic... but unix-y, not DOS-ish! (I always find this kind
> of startling/confusing whenever i see it.) But again, *greatly* appreciate
> the conversion to short file names.
>
> o File > Save File removes blank lines between paragraphs. (Because i
> didn't put a space character there?) A little quirky to have to do that.
>
>
> As always, many thanks for all the work....
>
> - Doug B.

Hi Doug,

thank you for your message and testing FlWriter. If you would start FlWriter with redir.exe from the DJGPP package you could redirect error messages to a file and that should give a clue why the PDF conversion does not work. It does work here.
You can also make a postscript file and convert that with the included ps2pdf.bat file after exiting FlWriter from the command line. That could also show the error.

The ESC key is similar in nano-X to CTRL-C in DOS command mode. It will terminate nano-X and restore the text display. Sometimes it can be useful. I will document that in the readme file next time.

I thought I had fixed that blank lines are removed when saving. This has to be fixed. Yes, the workaround is to add a blank here.

Georg

Doug

08.05.2012, 03:48

@ georgpotthast

FlWriter version 1.1 available

Post reply

> If you would start
> FlWriter with redir.exe from the DJGPP package you could redirect error
> messages to a file and that should give a clue why the PDF conversion does
> not work.

Ok, i'm using 4DOS, so i can redirect standard error as well as standard output. Ran FlWriter with this command:
flwriter >& err
Loaded the test file, tried to create a PDF, failed same as previous note. Contents of the "ERR" file:
DOS/32A fatal (4003): not enough extended memory to load application exec "gs386.exe" Deleting d:\flwriter\outtmp.ps 1 file deleted 163,840 bytes freed
Surprising... because the system has 512mb RAM! The MEM command in DOS displays:
Memory Type Total Used Free ---------------- -------- -------- -------- Conventional 638K 15K 623K Upper 96K 54K 42K Reserved 0K 0K 0K Extended (XMS) 522,592K 1,805K 520,787K ---------------- -------- -------- -------- Total memory 523,326K 1,874K 521,452K Total under 1 MB 734K 69K 665K Largest executable program size 623K (638,096 bytes) Largest free upper memory block 38K (39,328 bytes) Available space in High Memory Area 11K (10,800 bytes) MS-DOS is resident in the high memory area.
I'm enabling XMS and UMBs with Uwe Sieber's UMBPCI and Jack Ellis's XMgr.

Any clues?

- Doug B.

Rugxulo

Usono,
08.05.2012, 05:44

@ Doug

FlWriter version 1.1 available

Post reply

> Ok, i'm using 4DOS, so i can redirect standard error as well as standard
> output. Ran FlWriter with this command:
> > flwriter >& err >
> Loaded the test file, tried to create a PDF, failed same as previous note.
> Contents of the "ERR" file:
> > DOS/32A fatal (4003): not enough extended memory to load application exec > "gs386.exe" >
> Surprising... because the system has 512mb RAM!
>
> I'm enabling XMS and UMBs with Uwe Sieber's UMBPCI and Jack Ellis's XMgr.
>
> Any clues?

I'm far from an expert at memory internals, but DOS extenders are weird. Sometimes they get confused or have conflicts. Try again without UMBPCI. Or, if you're adventurous, you can get SS.EXE (from dos32a-912-bin.zip) and try changing the memory configuration of your dos32a.exe file (and/or gs386.exe). You could also try re-stubbing gs386.exe with something else (Causeway, D3X, WDOSX, ...). Or try loading "hdpmi32 -r" first. EDIT: In fact, FLWRITER.EXE and PDF2HTML.EXE are built with DJGPP, hence they prefer CWSDPMI, which is only a "pure DPMI" host, not extender like OpenWatcom typically wants. I've often seen conflicts between the two, so you may wish to load "hdpmi32 -r" first to be consistent or re-stub with D3X, as those (more or less) seem fairly sane.

P.S. Georg, it looks like you UPX'd gs386.exe but forgot to wstrip.exe it first. (Or whoever compiled gs386.exe, anyways.)

georgpotthast

Germany,
08.05.2012, 21:45
(edited by georgpotthast, 08.05.2012, 22:14)

@ Rugxulo

FlWriter version 1.1 available

Post reply

FlWriter starts gs386.exe as a subprocess including a second shell and leaving cwsdpmi and its files in memory. On my PC this leaves 367kb for gs386.exe and that does only allow to convert small postscript files to PDF. You can shell to DOS from the FlWriter menu and run mem.exe to see how much memory is left.

I added the ps2pdf.bat file into the directory. If you make a postscript file e.g. from the readme.htm file, you can exit FlWriter(not shell to DOS) and call "ps2pdf.bat readme" (not readme.ps) to generate a PDF file with all the memory available for gs386.exe.

Rugxulo, I will also see if I can run strip with gs386.exe but I doubt that this will gain a lot of memory space compared to what cwsdpmi already requires. Yes, hdpmi32 will probably help - if you do not want to do it from the command line.

Georg

I just tried it. Yes, wstrip will reduce the size of gs386.exe. But in real mode DOS I could make a PDF file from readme.htm with both versions of gs386.exe using the menu. It takes quite a long time though! I only had 285kb available not 367kb as mentioned above.

Rugxulo

Usono,
09.05.2012, 06:51

@ georgpotthast

FlWriter version 1.1 available

Post reply

> FlWriter starts gs386.exe as a subprocess including a second shell and
> leaving cwsdpmi and its files in memory. On my PC this leaves 367kb for
> gs386.exe and that does only allow to convert small postscript files to
> PDF. You can shell to DOS from the FlWriter menu and run mem.exe to see how
> much memory is left.

CWSDPMI has a minor design flaw of keeping page tables in low RAM. Most other extenders didn't do it this way (and it wouldn't be trivial to fix / test). But "usually" it doesn't bite anyone. Though of course HDPMI32.EXE is much more efficient. You could just lump that in and call it via F.BAT (hdpmi32 -r, flwriter.exe, hdpmi32 -u).

> Rugxulo, I will also see if I can run strip with gs386.exe but I doubt that
> this will gain a lot of memory space compared to what cwsdpmi already
> requires. Yes, hdpmi32 will probably help - if you do not want to do it
> from the command line.

Actually, I just mentioned wstrip because of .EXE bloat. I have no idea if it affects the memory footprint. (Debug info doesn't for DJGPP, but I'm not sure it's the same for OpenWatcom.) I just thought it was worth shaving. ;-)

> I just tried it. Yes, wstrip will reduce the size of gs386.exe. But in real
> mode DOS I could make a PDF file from readme.htm with both versions of
> gs386.exe using the menu. It takes quite a long time though! I only had
> 285kb available not 367kb as mentioned above.

Believe it or not, here's the deal: you're using old CWSDPMI r5 from 2000. A DJGPP .EXE will always run the CWSDPMI that is closest to itself (e.g. same dir preferred over path), which in this case is less than ideal because r7 is more efficient (4 MB pages when using large allocations). If you don't want to use HDPMI32, you may want to at least use CWSDPMI r7.

For instance, on my PC, shelling out to DOS:

CWSDPMI r5 = 316k free
CWSDPMI r7 = 368k free
WDOSX 0.97 = 456k free
HDPMI32 3.17 = 583k free

Doug

09.05.2012, 07:53

@ Rugxulo

FlWriter version 1.1 available

Post reply

> try loading "hdpmi32 -r" first

That did it! I didn't have to use the "-r" switch though -- just running HDPMI32.EXE right before FLWRITER.EXE did the trick -- PDF created just fine.

Out of curiosity, i also tried explicitly running CWSDPMI.EXE from the command line right before FLWRITER.EXE -- PDF creation still failed. I tested CWSDPMI r5 as well as r7 -- same results for both.

MEM after "Shell to DOS" from within FlWriter for my default system configuration (CWSDPMI r7):
Memory Type Total Used Free ---------------- -------- -------- -------- Conventional 638K 199K 439K Upper 96K 96K 0K Reserved 0K 0K 0K Extended (XMS) 522,592K 522,208K 384K ---------------- -------- -------- -------- Total memory 523,326K 522,503K 823K Total under 1 MB 734K 295K 439K Largest executable program size 439K (449,024 bytes) Largest free upper memory block 0K (224 bytes) Available space in High Memory Area 8K (7,888 bytes) MS-DOS is resident in the high memory area.
MEM after "Shell to DOS" from within FlWriter after running HDPMI32 first:
Memory Type Total Used Free ---------------- -------- -------- -------- Conventional 638K 44K 594K Upper 96K 62K 34K Reserved 0K 0K 0K Extended (XMS) 64,416K ? 480,619K ---------------- -------- -------- -------- Total memory 65,150K ? 481,247K Total under 1 MB 734K 106K 628K Largest executable program size 594K (607,872 bytes) Largest free upper memory block 34K (34,720 bytes) Available space in High Memory Area 8K (7,888 bytes) MS-DOS is resident in the high memory area.
Very-different results on the "Extended (XMS)" lines!

(Keep in mind that i'm using 4DOS v8.0 -- not COMMAND.COM.)

- Doug B.

Rugxulo

Usono,
09.05.2012, 08:43

@ Doug

FlWriter version 1.1 available

Post reply

> > try loading "hdpmi32 -r" first
>
> That did it! I didn't have to use the "-r" switch though -- just running
> HDPMI32.EXE right before FLWRITER.EXE did the trick -- PDF created just
> fine.

Good, but ...

> Very-different results on the "Extended (XMS)" lines!

If you have DJGPP, it doesn't (directly) use anything but DPMI. So what EMS or XMS or raw or whatever it uses depends on the DPMI host program. If you run "go32-v2" (assuming you have it, it comes with DJGPP), it will tell you how much DPMI is available. Or try \hx\test\dpmi.exe instead. (I don't know which DOS or 3rd-party MEM.EXE you're using, but I know FreeDOS' often reports invalid numbers. I get all kinds of weird DOS behavior on this machine thanks to too much RAM.)

Anyways, glad it works for you, but I actually wanted to report my own attempt:

native FreeDOS 1.1, JEMM386 "NOEMS": didn't work

I don't really have any .PS files, so I just grabbed the 1.4 MB one from DJGPP's faq230p.zip. Long story short ...

gs386 exe 1,241,322 pdf2html exe 333,608 pcl bat 161 ps2pdf bat 163 djgppfaq ps 1,468,976 23 items: 7 dirs, 16 files totaling 4,726,025 bytes Wed May 09,2012 01:20:10.59am; 138,153,984 bytes free Video mode 3 (80*43) on video page 0 Volume label is HalleLU-Jah [ FreeDOS ] G:\TONY\FLWRITER>ps2pdf djgppfaq [ FreeDOS ] G:\TONY\FLWRITER>gs386 -q -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=d jgppfaq.pdf djgppfaq.ps -c quit DOS/32A -- DOS Extender version 9.1.2 Copyright (C) 1996-2006 by Narech K. Error: /VMerror in -file- VM status: 0 495460 503296 Current allocation mode is local Last OS error: 1 Current file position is 91351 GNU Ghostscript 7.05: Unrecoverable error, exit code 1 [ FreeDOS ] G:\TONY\FLWRITER>upx -qqqd gs386.exe [ FreeDOS ] G:\TONY\FLWRITER>stubit gs386.exe >nul [ FreeDOS ] G:\TONY\FLWRITER>ps2pdf djgppfaq [ FreeDOS ] G:\TONY\FLWRITER>gs386 -q -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=d jgppfaq.pdf djgppfaq.ps -c quit [ FreeDOS ] G:\TONY\FLWRITER>memid PMODE VCPI 1.0 XMS 3.0 [ FreeDOS ] G:\TONY\FLWRITER>vv *.pdf G:\TONY\FLWRITER\*.PDF djgppfaq pdf 11,464,348 May,09,2012 01:21:00am A... [ FreeDOS ] G:\TONY\FLWRITER>scrndump c:\tmp\georgems.txt

So by default it wasn't working under JEMM386 for me. (Similarly, just in general use, D3X also has issues under JEMM386 here.) Actually, I didn't fudge with DOS32A.EXE or GS386.EXE at all (not even via SS.EXE), but it obviously has different ways of handling things. I think I've read comments on the DR-DOS FAQ site (written by DOS386 ?) that DOS/32A implements its own DPMI host, ignoring the existing one, when under VCPI. I don't know how true that is, but anyways, the above error message leaves a lot to be desired.

So re-stubbing with WDOSX (which needs UPX unpacking first else says "wrong exe type") works fine. Not that I recommend WDOSX by default, it has some issues with CWSDPMI shelling out to use it (though HDPMI32 handles it fine). But standalone it works okay, at least to prove a point. And MuPDF does view the resulting .PDF file okay, so it seems to have worked (and took about 10 secs to generate, dunno if that's considered "slow" or quick for you, Georg). And yes, BTW, I rebooted to XMS only (XMGR) and it worked without any problems by default. So there. Hope this (barely) helps! :-P :-D

georgpotthast

Germany,
09.05.2012, 20:23

@ Rugxulo

FlWriter version 1.1 available

Post reply

I do not load emm386 since I do not seem to need it. So now I loaded "jemm386 noems load" from the command line. I use MSDOS 7.0 with its HIMEM.

This allowed to convert djgppfaq.ps to djgppfaq.pdf with the ps2pdf.bat file ok. It took 50 seconds though, 40 secondes without jemm386.

When jemm386 was loaded there was not enough memory to run this batch file from the DOS shell. It was possible when using HDPMI32 -r instead of cwsdpmi.

Since I could not reproduce your problem here I currently do not want to use wdosx instead of DOS32A.

Georg

Rugxulo

Usono,
09.05.2012, 22:39

@ georgpotthast

FlWriter version 1.1 available

Post reply

> I do not load emm386 since I do not seem to need it.

I normally wouldn't either, but I've been running with it for a month or two just for laughs / experimentation, ever since that freedos-user thread where I said it wasn't necessary and some people disagreed. Having seen a few small issues over the weeks, I would agree it's not necessary (or even better to avoid it until needed and only then JEMM386 LOAD at will, unless you really really need UMBs all the time).

> Since I could not reproduce your problem here I currently do not want to
> use wdosx instead of DOS32A.

No, I wouldn't either, I just wanted to prove a point about how some problems are with extenders and not so much with lack of RAM or DOS or the apps (FLWriter) themselves.

The simple truth is that some (most?) extenders and DPMI hosts were never tested with such high amounts of RAM in all situations. And since most aren't updated anymore, it's kinda a crapshoot what will work and what won't.

Rugxulo

Usono,
10.05.2012, 14:21

@ georgpotthast

FlWriter version 1.1 available

Post reply

> I do not load emm386 since I do not seem to need it. So now I loaded
> "jemm386 noems load" from the command line. I use MSDOS 7.0 with its
> HIMEM.
>
> This allowed to convert djgppfaq.ps to djgppfaq.pdf with the ps2pdf.bat
> file ok. It took 50 seconds though, 40 secondes without jemm386.

So it works for you with (J)EMM386 / VCPI loaded? Not for me.

> When jemm386 was loaded there was not enough memory to run this batch file
> from the DOS shell. It was possible when using HDPMI32 -r instead of
> cwsdpmi.

I'm talking outside of FLWriter entirely, even then it doesn't work for me. Perhaps there is some other way to tweak things, but I'm not sure offhand (besides weird hack below).

> Since I could not reproduce your problem here I currently do not want to
> use wdosx instead of DOS32A.

This is all still confusing. I don't know if you're experiencing what I am. In any case, my problem seems to be JEMM386 + DOS/32A (though presumably it's only the latter's fault as Causeway, e.g. "cwstub gs386.exe ..." works fine similarly to WDOSX). For me, even with "hdpmi32 -r" loaded, ps2pdf won't succeed when under JEMM386 / VCPI.

DOS/32A 9.1.2 by default nowadays "always" (!) prefers VCPI over DPMI. Don't know why, presumably bugs in other software. Worse is that you can't configure it anymore, and hence even the DPMITST:ON option is commented out and unsupported. Seems strange to always force it in all circumstances (esp. given how many variations in setups there are).

Without changing extenders, the easiest "fix" is something I heard from Japheth a while back. "hdpmi32 -r", "jemm386 novcpi", "ps2pdf djgppfaq", "jemm386 vcpi", "hdpmi32 -u". Then it has no choice but to use DPMI. Or similar, of course, maybe don't even need HDPMI32 specifically, but it's too cool to totally avoid. ;-)

georgpotthast

Germany,
10.05.2012, 22:04

@ Rugxulo

FlWriter version 1.1 available

Post reply

I hope this discussion will not give the impression to potential users of FlWriter that you can only use the software if you know how to handle potential conflicts of VCPI and DPMI and try out different DOS extenders. As long as you do not use EMM386 - which none of us three believes he really needs - no problems did arise so far.

I entered on the command line:
"jemm386 vcpi load"
"ps2pdf djgppfaq"

works slow but without problems here.

Georg

Rugxulo

Usono,
11.05.2012, 00:22

@ georgpotthast

FlWriter version 1.1 available

Post reply

> I entered on the command line:
> "jemm386 vcpi load"
> "ps2pdf djgppfaq"
>
> works slow but without problems here.

Works fine for me ... when EMS is enabled (!), but with "JEMM386 NOEMS", DOS/32A seems to get confused. This is probably a bug, but whatever, I doubt he's up for updating it (2006, meh). If it makes you feel any better, his PAE hack beta reboots the machine (only) when under JEMM386 also. ;-)

georgpotthast

Germany,
11.05.2012, 08:07

@ Rugxulo

FlWriter version 1.1 available

Post reply

> > I entered on the command line:
> > "jemm386 vcpi load"
> > "ps2pdf djgppfaq"
> >
> > works slow but without problems here.
>
> Works fine for me ... when EMS is enabled (!), but with "JEMM386 NOEMS",
> DOS/32A seems to get confused. This is probably a bug, but whatever, I
> doubt he's up for updating it (2006, meh). If it makes you feel any better,
> his PAE hack beta reboots the machine (only) when under JEMM386 also. ;-)

Quite some time ago I observed that MS-DOS Edit would not run using DOS 7.0 if I set the NOEMS switch. Since then I never used it again.

By the way, do you plan to update your bare-bone distribution to FreeDOS 1.1 ?

Georg

Rugxulo Usono, 11.05.2012, 22:27 @ georgpotthast	FlWriter version 1.1 available Post reply
	> By the way, do you plan to update your bare-bone distribution to FreeDOS > 1.1 ? I wasn't planning on it, no, esp. since nobody else uses floppies anymore. (I assume you mean the "BARE_DOS" minimal, one-floppy image. It shouldn't be too hard to manually update, but it's not high priority by any stretch.)

RayeR

CZ,
12.05.2012, 00:36

@ Rugxulo

FlWriter version 1.1 available

Post reply

> I wasn't planning on it, no, esp. since nobody else uses floppies anymore.
> (I assume you mean the "BARE_DOS" minimal, one-floppy image. It shouldn't
> be too hard to manually update, but it's not high priority by any stretch.)

I still use floppies (ocassionaly) and I'm afraid that new mobos doesn't have FDC. Of course there are USB FDD and maybe they can even boot but sometimes BIOS USB emulation badly affect booted system...

---
DOS gives me freedom to unlimited HW access.

georgpotthast

Germany,
12.05.2012, 08:40

@ RayeR

FlWriter version 1.1 available

Post reply

> > I wasn't planning on it, no, esp. since nobody else uses floppies
> anymore.
> > (I assume you mean the "BARE_DOS" minimal, one-floppy image. It
> shouldn't
> > be too hard to manually update, but it's not high priority by any
> stretch.)
>
> I still use floppies (ocassionaly) and I'm afraid that new mobos doesn't
> have FDC. Of course there are USB FDD and maybe they can even boot but
> sometimes BIOS USB emulation badly affect booted system...

There was a thread in freedos-user which showed that many DOS users are running DOS in a virtual machine of some kind. A floppy image can be used with that and is easier to download than the full FreeDOS CD.

And with the El-Torito standard you can also make bootable CDs from a floppy image.

Rugxulo wrote to me that his new PC does not have a floppy drive any more and it took him quite a lot of time to compile the floppy image in the first place.
On the other hand I removed quite a lot of the utilities from the bare-dos image again because I did not need it. I see it more as a base for an embedded DOS application. (Puppy DOS / Tiny Core DOS :-) )

Georg

Rugxulo

Usono,
13.05.2012, 01:44

@ georgpotthast

GhostScript 7.05 for DOS

Post reply

BTW, I have grabbed two alternate copies of GhostScript 7.05 for DOS, both apparently using DJGPP, but I'm not sure if they are 100% compatible. I don't know if those are better for your use or not. I suppose they could lack some patches or support that yours has, who knows. (I've not barely used GhostScript at all, ever, because I never need it, and it's very confusing with millions of supplementary junk.)

http://www.caddit.net/engineering/programming/

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/gs/7.05/

If anybody knows which GhostScript version(s) is the "best" overall (or why or ...), please tell us.

georgpotthast Germany, 13.05.2012, 10:00 @ Rugxulo	GhostScript 8.71 for DOS Post reply
	The latest version I am aware of is here: Ghostscript 8.71 I did not use that since it is a 18 MB download which expands to 25 MB and I did not want to make the FlWriter package that big. Georg

Rugxulo

Usono,
22.05.2012, 01:07

@ georgpotthast

GhostScript 8.71 for DOS

Post reply

BTW, I hate to bump this thread for just a generic mention of memory woes, but I'd rather semi-document it here than totally forget about it.

I've more or less given up on using EMM386 (except in rare cases), e.g. default on at bootup. Despite the UMB advantage (which is fairly small for my uses), it just doesn't work well in some corner cases. This is not a fault of EMM386 or even JEMM386, almost definitely it's a fault of certain other tools (CWSDPMI, DOS32A). I can probably work around it, but it's not really worth the end-user confusion.

In other words, I was using "JEMM386 NOEMS MAX=0", which was not handled properly by DOS32A. I guess he was always trying to (exclusively?) malloc via EMS when no EMS nor page frame was available. Default for JEMM386 is "MAX=120000" (120 MB) of EMS. Unfortunately, we all know that some tools use more than that, sadly, so that's not reliable either. And I tried setting it to "MAX=520000" (good enough for 99% of potential uses, I thought), but that just shows a persistent CWSDPMI "reg dump / won't run" bug (which is already semi-reported from months ago, though CWS is ultra busy these days). So I dunno, it's kinda a mess.

In short, it's easier to my uses, esp. since FreeDOS is already pretty efficient in conventional memory (560 kb free?) to not need UMBs to maximize that. So I can just "JEMM386 LOAD" at runtime when EMS is necessary for something.

P.S. Perhaps I should've taken a text screenshot of the CWSDPMI regdump, which was a killer bug, and who knows why exactly it fails (not me!). But anyways, better play it safe, I suppose, and go XMS only. I guess I was naive in thinking all extenders were smart about being totally configurable or preferring XMS over EMS/VCPI or that EMM386 always shares total RAM between XMS and EMS (not true for old MS-DOS versions, right??). Bah.

RayeR

CZ,
23.05.2012, 00:51

@ Rugxulo

GhostScript 8.71 for DOS

Post reply

It may be problem specific to your system hw/bios/freedos. I use JEMMex with EMS enabled and don't have any instant crashes of DPMI apps. My memory report:
+ Memory Type ------+-- Total Bytes ( Kbytes ) -+--- Available For Programs -+ | | | | | Conventional | 653,312 ( 638K ) | 620,352 ( 606K) | | Upper | 72,912 ( 71K ) | 48,128 ( 47K) | | High | 65,520 ( 64K ) | 12,512 ( 12K) | | Extended | 67,043,328 ( 65,472K ) | 0 ( 0K) | | Extended via XMS | -------- | 3,486,466,048 (3,404,752K) | | EMS | 33,947,648 ( 33,152K ) | 33,554,432 ( 32,768K) | +-------------------+----------------------------+----------------------------+ | Largest executable program: 620,256 ( 606K ) | | Total Free DOS memory: 668,480 ( 653K ) | +-----------------------------------------------------------------------------+ I use DOS 6.22 as reference and here's my part of config.sys: DOS=HIGH,UMB DEVICE=C:\DOS\JEMMEX.EXE A20METHOD:FAST XMSHANDLES=64 SPLIT SB FASTBOOT VERBOSE STACKS=9,256 BUFFERS=15 LASTDRIVE=Z FCBS=4,0 FILES=60 rem ATAPICD.SYS replaced by UIDE.SYS SHELL=C:\COMMAND.COM C:\ /E:1536 /P

---
DOS gives me freedom to unlimited HW access.

Rugxulo

Usono,
23.05.2012, 05:39

@ RayeR

GhostScript 8.71 for DOS

Post reply

> It may be problem specific to your system hw/bios/freedos. I use JEMMex
> with EMS enabled and don't have any instant crashes of DPMI apps. My memory
> report:
> [code]
> | Extended | 67,043,328 ( 65,472K ) | 0 (
> 0K) |
> | Extended via XMS | -------- | 3,486,466,048
> (3,404,752K) |
> | EMS | 33,947,648 ( 33,152K ) | 33,554,432 (
> 32,768K) |
>
> I use DOS 6.22 as reference and here's my part of config.sys:
>
> DEVICE=C:\DOS\JEMMEX.EXE A20METHOD:FAST XMSHANDLES=64 SPLIT SB FASTBOOT
> VERBOSE

I think default is "MAX=120000" (aka, 120 MB) of EMS for JEMM386. So the "32 MB" above is probably misreported. And I'm pretty sure some programs / extenders try to eat up more than that despite XMS also existing.

My problem was (effectively) using "XMSHANDLES=128 MAX=0 NOEMS" or "XMSHANDLES=128 MAX=512000" or thereabouts. CWSDPMI got confused (though whether that's also due to 150 MB XMS RAM disk, I dunno, but the simple answer is that all these memory things are a bit wonky under stress).

It's not lacking the RAM, sadly, it's trying to figure out which to use where, and these apps obviously can't handle it very well. ;-)

Doug

10.05.2012, 18:02

@ Rugxulo

FlWriter version 1.1 available

Post reply

> I don't know which DOS or 3rd-party MEM.EXE you're using, but I
> know FreeDOS' often reports invalid numbers.

The MEM program is the MS-DOS 7.1 one.

> If you have DJGPP, it doesn't (directly) use anything but DPMI.
> So what EMS or XMS or raw or whatever it uses depends on the DPMI
> host program.

Understood. But what i'm getting from this is that, according to the MEM results, under identical conditions... other than CWSDPMI vs. HDPMI32... when shelling to DOS from within FlWriter, MEM reports very-different "Extended (XMS)" lines:
Memory Type Total Used Free ---------------- -------- -------- -------- CWSDPMI: Extended (XMS) 522,592K 522,208K 384K HDPMI32: Extended (XMS) 64,416K ? 480,619K
So as you suggest, one possible scenario might be a quirk in the way MS 7.1 MEM reads XMS. But if not, doesn't this mean that GS386.EXE (from FlWriter) would think it has access to very-different amounts of extended memory under each? And it did choke under just CWSDPMI and succeed with HDPMI32.

Just curious....

> If you run "go32-v2" (assuming you have it, it comes with DJGPP), it
> will tell you how much DPMI is available. Or try \hx\test\dpmi.exe
> instead.

I have both. Will post some test results later if anyone's interested -- let me know.

- Doug B.

georgpotthast Germany, 09.05.2012, 08:29 @ Rugxulo	FlWriter version 1.1 available Post reply
	Hi Rugxulo, thank you for your suggestion. I will modify f.bat as you described. I have no objection against hdpmi32, Japheth makes excellent software. Regards Georg