DOS ain't dead

The new RC for FPC 2.2.2 with hopefully most, if not all, remaining bugs fixed is at

ftp://ftp.hu.freepascal.org/fpc/beta/2.2.2rc2/i386-go32v2/

Please give it a spin.

> The new RC for FPC 2.2.2 with hopefully most, if not all, remaining bugs
> fixed is at
>
> ftp://ftp.hu.freepascal.org/fpc/beta/2.2.2rc2/i386-go32v2/
>
> Please give it a spin.

I downloaded it yesterday, the bugs I reported with RC1 are gone - it is very good!
Smartlinking works really very well, when enabled I got similar file sizes like with FPC 1.0.10. Debugging also works while the size of FP.EXE remained to be quite small still. Bravo. (btw. which switches did you use for compilation?)
There is only one isssue with debugger in RC2. It doesn't save the output screen when you are in graph mode - IDE properly switches into graphics mode but only black screen is shown. FPC 1.0.10 did it properly. It is a problem of FPC or problem in LIBGDB? What happens if you use a older version of LIBGDB?

Then two very small issues are still present:
* In example of FreeVision (TestApp): if you have no window opened (so the cursor is hidden) and choose from menu "Dosshell", then after returning into application is cursor visible (should be hidden) - is is a bug in FV

* In IDE if you change resolution (to 80x50 for example), the mouse cursor disapears. To make it visible again you have to press Alt-F5 and then any key. It is a bug in VESAMODE.PP (or vesamode.pas? - (I am not sure I am writting this in work))

* Source of INSTALL.PAS could be simplified - it contains some string functions which are already present in units Strings and SysUtils.

* example for CHM reader is missing
(I would like to write own reader for CHM help systems but it is not very clear to me how to use the CHM units)

* in documentation is missing a description how FPC passes arguments into procedures. It is very important for procedures in assembler.
(in oldfpccall via stack, in default by some registers, but how exactly?)

Not bug but a dream:
Some good sound library for DOS.

---
DOS-u-akbar!

I fixed the issue with TestApp and sent a patch into BugZilla.

---
DOS-u-akbar!

> I downloaded it yesterday, the bugs I reported with RC1 are gone - it is
> very good!

Good to hear.

> Bravo. (btw. which switches did you use for compilation?)

I'm afraid I can't take any credit, since I didn't fix or compile anything. Giulio did most of the work I think.

> There is only one isssue with debugger in RC2. It doesn't save the output
> screen when you are in graph mode - IDE properly switches into graphics
> mode but only black screen is shown. FPC 1.0.10 did it properly. It is a
> problem of FPC or problem in LIBGDB? What happens if you use a older
> version of LIBGDB?

I suspect it is an problem in the IDE. GDB doesn't do this, and this must be fixed actively by the IDE.
It could be that this is a problem that was fixed in 1.0 after 2.x was already branched off, but not merged because proto 2.x was a mess in 2000-2003.

Please open a report for it.

> Then two very small issues are still present:
> * In example of FreeVision (TestApp): if you have no window opened (so the
> cursor is hidden) and choose from menu "Dosshell", then after returning
> into application is cursor visible (should be hidden) - is is a bug in FV

I saw you posted a report+ fix for that.

> * In IDE if you change resolution (to 80x50 for example), the mouse cursor
> disapears. To make it visible again you have to press Alt-F5 and then any
> key. It is a bug in VESAMODE.PP (or vesamode.pas? - (I am not sure I am
> writting this in work))

I saw the bugreport. I think it is a vesa implementation quirk (not properly keeping cursor style across modes, so this might not happen on all systems), but explicitely setting the last mode after a resolution change might help.

Hmm. I btw saw you also have this open:
http://bugs.freepascal.org/view.php?id=9863
can you update its status?

> * Source of INSTALL.PAS could be simplified - it contains some string
> functions which are already present in units Strings and SysUtils.

I'll ask Florian about this, and clean up if necessary. The installer is older than sysutils in the first place.

> * example for CHM reader is missing
> (I would like to write own reader for CHM help systems but it is not very
> clear to me how to use the CHM units)

Known issue. Not much I can do atm. It was a donation.

> * in documentation is missing a description how FPC passes arguments into
> procedures. It is very important for procedures in assembler.
> (in oldfpccall via stack, in default by some registers, but how exactly?)

I don't have the time to search this, but afaik this is in the manual somewhere? It might help to know that the default convention is equal to the "register" calling convention. Will check myself later.

> Not bug but a dream:
> Some good sound library for DOS.

There might be something on the contrib page (splay?) if it ever comes up again.

> > * In IDE if you change resolution (to 80x50 for example), the mouse
> cursor
> > disapears. To make it visible again you have to press Alt-F5 and then
> any
> > key. It is a bug in VESAMODE.PP (or vesamode.pas? - (I am not sure I am
> > writting this in work))
>
> I saw the bugreport. I think it is a vesa implementation quirk (not
> properly keeping cursor style across modes, so this might not happen on
> all systems), but explicitely setting the last mode after a resolution
> change might help.
>
> Hmm. I btw saw you also have this open:
> http://bugs.freepascal.org/view.php?id=9863
> can you update its status?

Well, I checked it again. More likely the problem is not in VESAMODE.PP but in MOUSE.PP in procedure DoCustomMouse.
I will look at it when I come home.

---
DOS-u-akbar!

> > Not bug but a dream:
> > Some good sound library for DOS.
>
> There might be something on the contrib page (splay?) if it ever comes up
> again.

Ever tried DUGL Plus?

> Starting from the version 1.10 alfa1 DUGL is Bundled with an addon
> open source library DUGL-Plus which provides a C++ GUI, Sound with
> loadable asm sound drivers, and more image loading saving

> > > Not bug but a dream:
> > > Some good sound library for DOS.
> >
> > There might be something on the contrib page (splay?) if it ever comes
> up
> > again.
>
> Ever tried DUGL Plus?

Ugly license. No commercial use possible in any way it seems.

> > There is only one isssue with debugger in RC2. It doesn't save the
> output
> > screen when you are in graph mode - IDE properly switches into graphics
> > mode but only black screen is shown. FPC 1.0.10 did it properly. It is
> a
> > problem of FPC or problem in LIBGDB? What happens if you use a older
> > version of LIBGDB?
>
> I suspect it is an problem in the IDE. GDB doesn't do this, and this must
> be fixed actively by the IDE.
> It could be that this is a problem that was fixed in 1.0 after 2.x was
> already branched off, but not merged because proto 2.x was a mess in
> 2000-2003.

YES!
The responsible part of code is in \IDE\FPUSRSCR.PAS
I added a note into my older bugreport about this:
http://bugs.freepascal.org/view.php?id=9853

---
DOS-u-akbar!

and sent a patch solving the "hidding mouse after videomode change" problem.
http://bugs.freepascal.org/view.php?id=11699

---
DOS-u-akbar!

> > Ever tried DUGL Plus?
>
> Ugly license. No commercial use possible in any way it seems.

While I also agree that some licenses are not very nice, in practice do you (FreeBSD 64-bit user) really want to commercially write DOS apps?? Didn't think so.

> and sent a patch solving the "hidding mouse after videomode change"
> problem.
> http://bugs.freepascal.org/view.php?id=11699

Could you test if the following bugreport is related? It also seems to be about Graph problems in the IDE:

http://bugs.freepascal.org/view.php?id=8406

> > and sent a patch solving the "hidding mouse after videomode change"
> > problem.
> > http://bugs.freepascal.org/view.php?id=11699
>
> Could you test if the following bugreport is related? It also seems to be
> about Graph problems in the IDE:
>
> http://bugs.freepascal.org/view.php?id=8406

Well, my first impressions say: "Yes, it is related".
There are definitely bugs in unit Graph. It doesn't draw some graphics primitives (but some does - strange)

program Init_gr_4;
uses graph;
 var gd,gm: integer;
 begin
    gd:=detect;
    gm:=0;
    InitGraph(gd,gm,'');
    if GraphResult<>grok then halt;
 setcolor(cyan);
 setfillstyle(1,yellow);
 circle(320,200,100);
 line(0,0,getmaxx,getmaxy);
 PieSlice(500,500,200,0,90);
 Bar(10,10,400,300);
 outtextxy(100,100,'TEXT');
 readln;
 CloseGraph;
end.

In this source only filled objects are drawn, other not - interresting.
Unfortunately just now I don't have time to look at it more deeply. Maybe tomorrow. However, in wednesday I'll go to Russia (Syberia, Kemerovskaya oblast) and for 14 will be without internet. So I am afraid I'll not be able to help.

But it should be very easy to fix it because unit Graph is rather small and doesn't have any dependencies to other packages.

---
DOS-u-akbar!

> > Ever tried DUGL Plus?
>
> Ugly license. No commercial use possible in any way it seems.

Here the DUGL Plus License

>>1 -
>>
>>THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND EITHER
>>EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
>>WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
>>
>>2 -
>>
>>THE Author of DUGLPLUS grants you a non-exclusive, royalty-free right
>>to use, reuse, redistribute the Software, and all it's sources if you :
>>
>>. Do not pretend that you made it.
>>
>>. Acknowledge somewhere in your documentation and or website
>> that you have used the DUGLPLUS sources.
>>
>>. Use it to develop a DOS operating system based software.


This mean that you can use DUGL Plus for any purpose freely. But Only the loadable sound drivers are 100% independent from the core DUGL library.

On the case of using the core DUGL Lib, it's possible to use it commercially with my authorization.

>
> Here the DUGL Plus License
>

BTW, I meant to mention, here's an (old) Linux-only (??) MMX emulation library. Maybe you can take a look.

http://www-sop.inria.fr/members/Sylvain.Pion/progs/mmx-emu/

BTW, ever considered SSE2? I know CWSDPMI doesn't enable it (yet), but there are ways around that (e.g. use HDPMI32).

No, I'm not personally in favor of requiring MMX (or newer) for everything. However, you can always optionally use it if your computer supports it (may as well in that case). GCC is starting to support it ("-march=native -msse2"; something like "-ftree-vectorize" may/may not be enabled in -O3, maybe only in 4.3.0, I forget ...).

>
> BTW, I meant to mention, here's an (old) Linux-only (??) MMX emulation
> library. Maybe you can take a look.
>
> http://www-sop.inria.fr/members/Sylvain.Pion/progs/mmx-emu/

Yes but if i take the QEMU case, the emulated MMX is MUCH slower than an ordinary 386 or 486 rendering assembler code.
BTW the DUGL Plus SB16 driver require only a 486.

> BTW, ever considered SSE2?

SSE and SSE2 are very useful on 3D and matrix computation, Any one interested developing a 3D engine with DUGL ?

> No, I'm not personally in favor of requiring MMX (or newer) for
> everything.

Yes not every thing but MMX increase highly the rendering speed with a software renderer. for example we can ADD 2 int32 on a single asm instruction.
On the case of DUGL it requires a VESA 2.0 too, which appeared nearly on the same period as MMX, 1996-97.

> This mean that you can use DUGL Plus for any purpose freely. But Only the
> loadable sound drivers are 100% independent from the core DUGL library.

> On the case of using the core DUGL Lib, it's possible to use it
> commercially with my authorization.

As Rugxulo says , it is a currently bit hypothetical (though I did have something to do with Dos based POS in the past), but:

The point is more or less that I would want to know I was getting into up front. Free for commercial use is ok. Pay is also ok, but I would want to know up front. Asking authorization upfront before anything is a ackward (I didn't do anything yet, and have to bother you). Having to ask authorization and terms afterwards, after time investment is also not desirable.

If I understood the above correctly, the sound parts are usable without authorization.

But anyways, you might want to take this as an hint to clarify the website a bit, since I was originally reacting to the vagueness (as perceived by me) of the site :_)

Laaca: fun thing to play with if bored:

http://bugs.freepascal.org/view.php?id=6696

check the first comment, it is a description of this undoced feature.

> > Asking authorization upfront before anything is a ackward

I thing "before" you have a kind a full functional shareware library, you can try and test capabilities, stability and performance and decide if it's useful or not for a possible commercial project.

> > Having to ask authorization and terms afterwards, after time investment is > > also not desirable.

True. First i think that a company or a person does need an authorization for each commercial product. Authorization mean that this company or person have the right to make a commercial software.
Second redistributing DUGL, making wrapper, ... is always free, and it's up to the final user to respect the license.
Maybe I'm not a good commercial but for me there two important points :
- I really want to promote DOS as i think and believe that it's a very good OS alternative.
- I do wish that DUGL can generate enough income that i will go full time developing it.

> > But anyways, you might want to take this as an hint to clarify the website
> > a bit, since I was originally reacting to the vagueness (as perceived by
> > me) of the site :_)

I'm open to any proposal, suggestion as for the moment there is no commercial interest. Not sure what would be the best choice for a good development of both DOS and DUGL.

> > If I understood the above correctly, the sound parts are usable without
> > authorization.

Yes.