DOS ain't dead

FlWriter is a small word processor featuring a graphical user interface and WYSIWYG. It can output the edited text to postscript, PDF and RTF.

I ported this program to DOS. See further details and screenshots here:

FlWriter wiki entry

The download link for the beta1b version is:

http://code.google.com/p/nanox-microwindows-nxlib-fltk-for-dos/downloads/list

Wow!
Great, thank you!
But, please, add some example .BAT file how to setup necessary environment variables. I tried to adjust .BAT file from Dillo but somwthing is wrong because graphics mode is successfuly set, mouse cursor is visible, green clean desktop is drawn but nothing more happens.

---
DOS-u-akbar!

> Wow!
> Great, thank you!
> But, please, add some example .BAT file how to setup necessary environment
> variables. I tried to adjust .BAT file from Dillo but somwthing is wrong
> because graphics mode is successfuly set, mouse cursor is visible, green
> clean desktop is drawn but nothing more happens.

Laaca,

I do not use environment variables with FlWriter as I do with Dillo. You just have to have two separate directories one "flwriter" (again with its fonts subdirectory) and one "usr\share\htmldoc\data".

I observed the green screen as well sometimes, I started it again and it worked so I did not bother.
If nothing helps you may rename the xd640cfg directory in case the config file is corrupted.

Georg

I can reproduce this when renaming the fonts directory in the flwriter directory. So one of maybe several reasons for this is that FlWriter does not find these fonts. In general one can say it did not read successfully a file it needs to start.

I had observed this only occasionally before.

Georg

> I can reproduce this when renaming the fonts directory in the flwriter
> directory. So one of maybe several reasons for this is that FlWriter does
> not find these fonts. In general one can say it did not read successfully a
> file it needs to start.
>
> I had observed this only occasionally before.
>
> Georg


Can I place to main FlWriter directory into
C:\EDITORY\FLWRITER (and inside .\FLRITE and .\USR)

Or it must be placed in root?

---
DOS-u-akbar!

> > I can reproduce this when renaming the fonts directory in the flwriter
> > directory. So one of maybe several reasons for this is that FlWriter
> does
> > not find these fonts. In general one can say it did not read successfully
> a
> > file it needs to start.
> >
> > I had observed this only occasionally before.
> >
> > Georg
>
>
> Can I place to main FlWriter directory into
> C:\EDITORY\FLWRITER (and inside .\FLRITE and .\USR)
>
> Or it must be placed in root?

You can put the flwriter directory into another directory, e.g. \myprogs\tests\flwriter. But "\usr\share\htmldoc\data" has to be in root. However, this directory is only used by htmldoc.exe which is called for postscript and PDF conversions. So FlWriter should start even if "\usr\share\htmldoc\data" is not in root.

It will also run in a Windows XP DOS box.

Georg

> Wow!
> Great, thank you!
> But, please, add some example .BAT file how to setup necessary environment
> variables. I tried to adjust .BAT file from Dillo but somwthing is wrong
> because graphics mode is successfuly set, mouse cursor is visible, green
> clean desktop is drawn but nothing more happens.

I unpacked the zip to H:\ drive having both dirs in root and it did the same. GUI started but mouse din't moved, I could just press ctrl-break...
The same with doslfn.

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

I think there is a bug in your program when I try to save in pdf.

I write the name of the file and click on "accept" and the program creates two files: the file I have written and "readit.pdf", this second file is the right and the first one I don´t know what it is.

> I think there is a bug in your program when I try to save in pdf.
>
> I write the name of the file and click on "accept" and the program creates
> two files: the file I have written and "readit.pdf", this second file is
> the right and the first one I don´t what it is.

Hello Rob,

at least you can start the program

After you have LFN enabled, all you should do is click on the PDF button. This will save the current file - only ask for a name if that has not been done so - and then makes the readit.pdf file. All PDF files get this name for now. The name you have entered will allow you to open that file next time you start FlWriter. Or load it again if needed.

FlWriter saves its files in the HTML format. Therefore you should select a filename with the htm suffix.

Georg

> > Wow!
> > Great, thank you!
> > But, please, add some example .BAT file how to setup necessary
> environment
> > variables. I tried to adjust .BAT file from Dillo but somwthing is wrong
> > because graphics mode is successfuly set, mouse cursor is visible, green
> > clean desktop is drawn but nothing more happens.
>
> I unpacked the zip to H:\ drive having both dirs in root and it did the
> same. GUI started but mouse din't moved, I could just press ctrl-break...
> The same with doslfn.

I still don't know what the reason for this problem is.

- did you load a mouse driver?

- I forgot to add cwsdpmi.exe into the flwriter directory but if that would miss in your case the progam would not start at all

- can you start flwriter with the "redir" program from djgpp\bin please?
"redir -e err.log -o out.log flwriter" This way you can see any error messages send to STDERR in the err.log file.

- there is a nano-X environment variable which allows to reduce the colors to 16 bit if your graphics card or emulation requires it:
e.g. "set nanoscr=800 600 565"

Regards

Georg Potthast

Oh thanks :)

Another issue: the first time I enter I don´t have any problem but when I exit and try to enter again I can´t; the program freezes without the writing window, only the green screen and the mouse in the center.

> Hello Rob,
>
> at least you can start the program
>
> After you have LFN enabled, all you should do is click on the PDF button.
> This will save the current file - only ask for a name if that has not been
> done so - and then makes the readit.pdf file. All PDF files get this name
> for now. The name you have entered will allow you to open that file next
> time you start FlWriter. Or load it again if needed.
>
> FlWriter saves its files in the HTML format. Therefore you should select a
> filename with the htm suffix.
>
> Georg

> Another issue: the first time I enter I don´t have any problem but when I
> exit and try to enter again I can´t; the program freezes without the
> writing window, only the green screen and the mouse in the center.
>

Rob,

when can you run FlWriter - just once and then you need to reboot? Can you run "redir -e err.log -o out.log flwriter" on the second time and see if there are any error messages in the log files? (redir comes with DJGPP)

By the way, I just managed to compile the odt2txt utility with DJGPP:
http://www.bttr-software.de/forum/forum_entry.php?id=5861

Regards

Georg Potthast

I have discovered the problem: the program freezes if I use mupdf before (the Rayer's port, version 0.7)

>
> when can you run FlWriter - just once and then you need to reboot? Can you
> run "redir -e err.log -o out.log flwriter" on the second time and see if
> there are any error messages in the log files? (redir comes with DJGPP)
>

Good luck ;)

> By the way, I just managed to compile the odt2txt utility with DJGPP:
> http://www.bttr-software.de/forum/forum_entry.php?id=5861
>
> Regards
>
> Georg Potthast

> By the way, I just managed to compile the odt2txt utility with DJGPP:
> http://www.bttr-software.de/forum/forum_entry.php?id=5861

Cool! I can confirm that the original Win32 version works under HX. Do you have a link to your DJGPP binary?

(Looks like last update from program author was 2008-Jun.)

- Doug B.

> > By the way, I just managed to compile the odt2txt utility with DJGPP:
> > http://www.bttr-software.de/forum/forum_entry.php?id=5861
>
> Cool! I can confirm that the original Win32 version works under HX. Do
> you have a link to your DJGPP binary?
>
> (Looks like last update from program author was 2008-Jun.)
>
> - Doug B.

I just uploaded my package of ODT2TXT so you can take a look at it. As far as I could test it works as expected including German "umlauts".

I also compiled UNRTF which converts RTF to HTML. Not as well as FlWriter converts them to RTF but quite good. These utilities shall be included with FlWriter in the next version.

Georg

> I just uploaded my package of ODT2TXT so you can take a look at it. As far
> as I could test it works as expected including German "umlauts".

Does that run under plain DOS without HX ?
Never mind, I find it does. :)

And do you have a link to that ?
And I found that, too.

It works fine, and much faster than my own efforts (http://www.ausreg.com/files/odt2htm/) and with very similar results (at first glance).

Ron

Strange. On one my machine FlWrite works OK but on the second one it usually ends in the green desktop as I complained before. But not allways, sometimes it runs even on the second one machine...

---
DOS-u-akbar!

> Strange. On one my machine FlWrite works OK but on the second one it
> usually ends in the green desktop as I complained before. But not allways,
> sometimes it runs even on the second one machine...

This is a strange error. I can reproduce it when loading mupdf first. Why this does make any difference I do not know.

It is difficult to trace the error since the program works fine when run with GDB. When I enter "gdb flwriter" and "r" at the prompt it will run even when mupdf is run before.

I will keep working on it.

Georg

> > I just uploaded my package of ODT2TXT so you can take a look at it. As
> far
> > as I could test it works as expected including German "umlauts".
>
> Does that run under plain DOS without HX ?
> Never mind, I find it does. :)
>
> And do you have a link to that ?
> And I found that, too.
>
> It works fine, and much faster than my own efforts
> (http://www.ausreg.com/files/odt2htm/) and with very similar results (at
> first glance).
>
> Ron

Hi Ron,

I did not know that you wrote this program. I tried it and the resulting html file can be read into FlWriter.

Since its Freeware, could make the source code available? I would like to make a few changes to it so I can call it from FlWriter and it does not corrupt the display. Also a command line option for the output file name would enhance it.

Regards

Georg Potthast

> > It works fine, and much faster than my own efforts
> > (http://www.ausreg.com/files/odt2htm/) and with very similar results (at
> > first glance).
> >
> > Ron
>
> Hi Ron,
>
> I did not know that you wrote this program. I tried it and the resulting
> html file can be read into FlWriter.

> Since its Freeware, could make the source code available?

I can, but I don't think it will help.
I do not speak "C", and my progs are all coded with PBPlus+, by Joel Harper.
And it calls/uses other freeware utilities NOT written by me.
But I am happy to share it if you think it worthwhile.


> I would like to
> make a few changes to it so I can call it from FlWriter and it does not
> corrupt the display.

As I say, it is not written in C. But I can remove the on-screen displays if that is what you mean.

> Also a command line option for the output file name would enhance it.

Yes, I can do that.

Ron

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

> > > It works fine, and much faster than my own efforts
> > > (http://www.ausreg.com/files/odt2htm/) and with very similar results
> (at
> > > first glance).
> > >
> > > Ron
> >
> > Hi Ron,
> >
> > I did not know that you wrote this program. I tried it and the resulting
> > html file can be read into FlWriter.
>
> > Since its Freeware, could make the source code available?
>
> I can, but I don't think it will help.
> I do not speak "C", and my progs are all coded with PBPlus+, by Joel
> Harper.
> And it calls/uses other freeware utilities NOT written by me.
> But I am happy to share it if you think it worthwhile.
>
>
> > I would like to
> > make a few changes to it so I can call it from FlWriter and it does not
> > corrupt the display.
>
> As I say, it is not written in C. But I can remove the on-screen displays
> if that is what you mean.
>
> > Also a command line option for the output file name would enhance it.
>
> Yes, I can do that.
>
> Ron

Hi Ron,

yes I do not want to learn PB Plus.

a) Could you please make a quiet command line option e.g. "-q" so the command "odt2txt -q testtext.odt" will do no screen output. If possible just set the DOS errorlevel to 1 if the file could not be generated. In C the errorlevel would be set with a "return 1".

b) If the file name is "testtext.odt" could you call the output file "testtext.htm". Also put this name into the title.

Georg Potthast

I was able to reproduce the reported startup problem by running mupdf or make first. Now I made a new version called beta1c which does not show this startup problem here.

It can be downloaded using this link:

-> Download link for beta1c <-

Georg

> ->
> Download link for beta1c <-

This version works for me. There's still some oddity in file dialog. When it opens theres default path in window "h:/flwriter", when I set cursor behind "h" or ":" and press backspace it doesn't delete it but copy path string to
something like this "h:/flwriter/h/flwriter" and every press copy it again. But ALT+F dialog works now and I can select all my drives. This didn't worked in dillo.

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

> This version works for me. There's still some oddity in file dialog. When
> it opens theres default path in window "h:/flwriter", when I set cursor
> behind "h" or ":" and press backspace it doesn't delete it but copy path
> string to
> something like this "h:/flwriter/h/flwriter" and every press copy it again.
> But ALT+F dialog works now and I can select all my drives. This didn't
> worked in dillo.

Yes, your program works for me also, but I get that same behaviour with the file dialog box as well. Cursor doesn't erase the dialog like it should, pressing backspace just repeats eg: "D:\:D:\D:\", but using alt-f works.

This problem also affected me in Dillo browser... The only way I can open files directly in that program is to type them on the commandline when starting Dillo.

Otherwise, it is an excellent work, and another great DOS program. Thanks for porting it.

Hi Georg,

> a) Could you please make a quiet command line option e.g. "-q" so the
> command "odt2txt -q testtext.odt" will do no screen output.

I can do that for MY utility, but at least two of the other utilities called write messages to the screen.
I have, so far, been unable to stop that.


> b) If the file name is "testtext.odt" could you call the output file
> "testtext.htm". Also put this name into the title.

Done.

This below replaces the odt2htm.exe (or sits beside it - as it has a different name).

http://www.ausreg.com/files/odt2htm/o2h.exe

Use: o2h infile -q for (semi-)quiet operation

or: o2h infile for the "fully illustrated" version.

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

> > a) Could you please make a quiet command line option e.g. "-q" so the
> > command "odt2txt -q testtext.odt" will do no screen output.
>
> I can do that for MY utility, but at least two of the other utilities
> called write messages to the screen.
> I have, so far, been unable to stop that.

Direct screen writes? BIOS? I can't test here now, but perhaps you can make a .BAT and put "CTTY NUL" (beginning), blah.exe, and "CTTY CON" (end). Maybe that'll help.

> Direct screen writes? BIOS? I can't test here now, but perhaps you can make
> a .BAT and put "CTTY NUL" (beginning), blah.exe, and "CTTY CON" (end).

Thanks for the tip. :)

> Maybe that'll help.

No, it didn't. :(

Maybe it would work with redir, but I wonder if it's worth the effort.
Georg's utility does it much faster, without screen writes, and produces
a .txt file. Just the job for FlWrite !

Mine was really targeting Arachne as a plug-in, so an .htm output file
makes more sense there. And work on it stopped quite a while ago when I
got no interest from anyone else - even from those who said they would test
it. :)

Ron

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

Well the quiet mode is not really quiet, I guess the subprograms you link still output to the screen:

E:\myprogs\odt2htm>o2h testtext.odt -q
Datei nicht gefunden /*= file not found*/
Warning: TZ environment variable not found, cannot use UTC times!!
Archive: testtext.odt
extracting: ./mimetype
inflating: ./current.xml
inflating: ./content.xml
inflating: ./styles.xml
extracting: ./meta.xml
inflating: ./thumbnai.png
inflating: ./settings.xml
inflating: ./manifest.xml
Datei nicht gefunden

** CONTENT.XML **
Made 361 change(s) in out1 1 Datei(en) kopiert
Datei nicht gefunden

E:\myprogs\odt2htm>

It does not accept the -q variable it seems.

Since FlWriter uses the html format internally, odt2htm.exe is better for FlWriter than odt2txt.exe.

Georg

Glad that it works for you now. I did work on the file dialog in FLTK since FlWriter couldn't be used otherwise.

I usually just click on the filenames in the window or enter the file name at the end of the path in the input box. But you are right it still needs some work.

Georg

> Well the quiet mode is not really quiet, I guess the subprograms you link
> still output to the screen:

That is exactly right.

> E:\myprogs\odt2htm>o2h testtext.odt -q
> Datei nicht gefunden /*= file not found*/
> Warning: TZ environment variable not found, cannot use UTC times!!
> Archive: testtext.odt
> extracting: ./mimetype
> inflating: ./current.xml
> inflating: ./content.xml
> inflating: ./styles.xml
> extracting: ./meta.xml
> inflating: ./thumbnai.png
> inflating: ./settings.xml
> inflating: ./manifest.xml
> Datei nicht gefunden

Those are from unzip.exe

>
> ** CONTENT.XML **
> Made 361 change(s) in out1 1 Datei(en) kopiert
> Datei nicht gefunden

That is from texrep.exe


> It does not accept the -q variable it seems.

odt2htm.exe DOES accept the -q variable, the others don't.

> Since FlWriter uses the html format internally, odt2htm.exe is better for
> FlWriter than odt2txt.exe.

Then there is a reason to keep working with odt2htm.exe.
Time to look at alternatives to texrep.exe and unzip.exe, I think.

But is the output filename and title change OK ?

Ron

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

Ron,

yes, the output file name and title are OK!

Maybe you can call texrep.exe and unzip.exe with ">NUL". Unzip may have a -qq parameter to work silent.

Otherwise I will add odt2htm as a separate utility and the user has to convert his file before loading it into FlWriter.

Georg

> yes, the output file name and title are OK!

Good.

> Maybe you can call texrep.exe and unzip.exe with ">NUL". Unzip may have a
> -qq parameter to work silent.

No, it doesn't. But Rugxulo was correct and I did not understand.
It now works correctly with the -q switch:

http://www.ausreg.com/files/odt2htm/o2h.exe

Georg, see if this works for you now.

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

Hi Ron,

it is still not completely quiet see below.

E:\myprogs\odt2htm>o2h2 testtext.odt -q
Warning: TZ environment variable not found, cannot use UTC times!!
Datei nicht gefunden /*file not found*/

It converts ok though.

Regards

Georg

> Hi Ron,
>
> it is still not completely quiet see below.

> Warning: TZ environment variable not found, cannot use UTC times!!

That is from the UNZIP.EXE call. It is suppressed on my system (msdos 6.20).
The suppression is from a .bat file using CTTY NUL and CTTY MON as suggested by Rugxulo.

> Datei nicht gefunden /*file not found*/

That indicates that one of the "clean-up" actions fails to find a match.
If I can have a copy of your testtext.odt file, I can find and fix that.

Ron

The updated version works for me too.
Where was the problem?
It sound like a mystery that sometimes it started, sometimes not, depended on MuPDF...

---
DOS-u-akbar!

> The updated version works for me too.
> Where was the problem?
> It sound like a mystery that sometimes it started, sometimes not, depended
> on MuPDF...

It was apparently an uninitialised pointer. MuPDF (e.g.) left some data in memory which caused it to point where it wasn't supposed to point.

Georg