DOS ain't dead

> > Would you mind uploading sources?
>
> I can upload the sources I just wanted to see if anybody would be
> interested in them.

I just uploaded the sources for version 1.0

Georg

> I thought hmmm better download via wget,
Ok successfully d/l via wget. First thoughts re v1.0. Re size I stand by my comments above.

1)Fonts - you can halve your distribution by cutting down on fonts. I'd stick the main "common" fonts, e.g. ariel, courier, times into either a main.zip or mainfont.zip and then stick less common fonts e.g. dejas, vera, libmo etc in xtrafont.zip

2)font variations - ariela, arielb, arieli etc. Ok variations on the same basic font. Does the main distribution need so many variations? When I browse the font directory (on this nix box) I can see that each font has 4-5 variations where the variations are basically angle of characters and level of bold. As an end user how often would I ever use say arialz.ttf ? (right angled slant with bold) vs say arielb.ttf (bold left angled slant). I think I'd probably use arielz.ttf instead of either. I don't know but the choice seems large (which is good) but certainly I'd expect someone to use say arielz.ttf (as ariel is more popular) instead of say libmobi.ttf which is a less popular font.

There are various reports of most popular fonts - so if I was packaging this up I'd use something like that as a guide of what to include in a main.zip vs what to exclude and put into a xtrafont.zip

> > I used UPX with the executables and then ZIP with the package. Therefore
> > you do not gain much with a different compression program.

3)On one of my projects I once spent ages looking at compressing some data, trying different compressors/techniques before it then dawned on me that instead I could just avoid putting in the data in the first place. So with that in mind and building on my fonts comments, is there any data that is duplicated, e.g. for example DJ's stub.EXE which upx doesn't compress. An installer could for example programmatically copy a header which is stored once onto the top of various files which share that header.
EXE files is a bit of a bad example as harder to do (but not impossible) but hopefully you can see what I mean by that comment.

4)contools - ok so only 370k - a good example of something that could be separate download.

5) Main EXE's * 6 total = 4.6meg - ouch. Quick look at flwriter.exe after decompression. Quick thoughts:
strings - are there any common strings between EXE's that could be moved to external config files which would also aid translators.
bitmaps - uncompressed gfx. again any common gfx between exe's that could be moved externally to a single file.
redundant code present - e.g. I spotted a multiple re-occurances of NOP's 90h,90h,90h repeated patterns of code routines that re-occur multiple times.
[paging through EXE I got bored...]

I'd suggest running a strings util (e.g. strings.exe) over the each exe's pumping the output into a text file per EXE and looking to see what's common or redundant. Are you using all the strip functions of the compiler?

6) printer drivers - not sure what these take up but would suggest if large to include say an epson fx80 type driver, basic HP laser and have the others as optional (if need be) since most printers tend to support fallback to them.


Still really good project, so thank you again. I hope you see this as constructive feedback which is how it is intended. I realise though that it is possible to spend hours just on size alone and that there is a trade off but I do think this is an area that as others have said lets this great project down at the moment. There is just too much data in the distribution.

> One issue I found just after posting:
> DOS Shell doesn't work, at least in dosemu--the keyboard seems to be left
> dead.
> Suspect it might be an issue with a 32-bit program executing a 16-bit one.
> Haven't tested under pure dos yet.
>
> Also, I'm wondering about the USB printer drivers-- I have a USB "GDI"
> printer that's actually PCL5e, which should work if I can get communication
> using usbprint from Bret's USBDOS (or, assuming it supported printers then,
> the old "OEM" version of DOSUSB ;), which is buried somewhere on the hard
> drive of my other laptop...)
> I'm thinking about maybe creating the PCL5e file, exit, reboot with USB &
> load the driver, then try to print.

On one of the PCs I tested DOS Shell returned immediately. I could not locate the reason.

I am afraid a GDI printer will not work in real mode DOS. Even if you get USB communication to work using a DOS USB driver the GDI printer needs special data transfered over the USB link which is generated by the Windows printer driver or the equivalent in Linux. This can be undocumented commands for the print head and/or some special compression of the data send to the printer.

DOSEMU may emulate a DOS printer and then use the Linux printer driver to print that data.

Georg

> One issue I found just after posting:
> DOS Shell doesn't work, at least in dosemu--the keyboard seems to be left
> dead.

The DOS Shell of FLWriter v1.0 works ok for me using dosemu-1.4.0.0 under Linux:

-> Please enter EXIT to return to FlWriter <-


FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
F:\flwriter>ver /r
FreeDOS kernel build 2036 cvs [version Aug 18 2006 compiled Aug 18 2006]
F:\flwriter>

Same Linux box with DOSBox:

-> Please enter EXIT to return to FLWriter <-
[snip of DOSBOX boiler plate]

F:\FLWRITER>ver
DOSBox version 0.73. Reported DOS version 5.00.
F:\FLWRITER>

Same Linux box with Wine 1.1.31 / CMD Version 1.1.31 :

Fails - briefly shows "OS VGA" before returning to FLWriter.

Re the FLWriter under Wine; I was amazed it even ran under Wine's shell. Still it does however mouse handling seems a bit hit/miss although obviously not tested with latest version of Wine (that version is fine for my own testing at the min). I also noted speed wise it loaded/responded better than DOSBox under which FLWriter seemed to take an age to load and was slow to use.