DOS ain't dead

Roberto Perotti (iw2evk) wanted me to share this here for you guys:

http://sourceforge.net/projects/lodepaint/

> Hi,
>
> can you inform other dos user for my test on
> LODEPAINT sdl based paint program under HX
>
> The program seem work, but on my pc the screen it's spit in 2 parts .
> I've serched the configuration file settings.txt for change value like
> suggest in istructions, but i can't found it.
> I've alsoi try to creat the file with suggested value, but seem the
> program don't read this "fake" file.
> it's intersting program , and can be a candidate for sobstitute the
> last version of grafx2 (don't working under hx).
>
> Thanks
>
> Roberto iw2evk
>
> Milan

Personally, if I hadn't heard him say it mostly works, I'd never have believed it. Probably needs MSVCRT due to default SDL builds.

I guess I'll have to try it later. Other testers welcome.

> Roberto Perotti (iw2evk) wanted me to share this here for you guys

why ?

> http://sourceforge.net/projects/lodepaint/

I'll test.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

http://sourceforge.net/projects/lodepaint/

Where is the source code?

http://lodev.org/lodepng/

Tested:

+ WOW !!! WOW !!! WOW !!! WOW !!! WOW !!! WOW !!!

+ It runs with HX (needs 1024x768 screen ...) (see shot)

+ Very promising

+ I can pain[t] in it (pain[t]fully ...)

- GUI is hell slow and unresponsive

- Can neither load nor save, reason: uses "Get****FileName" (fixable according to TFM)

- Exit with [F12] crashes (HX BUG ?)

- Supplying file on commandline crashes (HX BUG ?)

The thing could get fixed in 3 ways:

* improve HX so it works as-is (still slowly)

* modify LOADPAINT to make it more HX-friendly (and even better, also faster)

* port it using some graphics library or SDLDOS



@rr : could you please send a (new or old) PWD to Roberto Perotti AKA iw2evk so that he doesn't have to use other people for posting here?

@Roberto Perotti AKA iw2evk : feel free to mail me if you have trouble posting elsewhere

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

I did test with HX. It seems to work but opening the window it:
1) " slow vido driver detected..... LodePain requires opengl .." ( I have ati agp 4x and/or S3; and opengl32.dll in hx-bin)
2) in the new opening window ".. icons_tools.prc not found in the skins dir"
3) program crashed
andrea

It does not work me.
LodePaint seems to requiere these DLLs: opengl32.dll, glu32.dll and crtdll.dll

I downloaded them from size dll-files.com but they are not compatible with HX because after putting these files into LodePaint main directory it doesn't load.
However it creates file STDOUT.TXT where is some initialization info and it seems that the switching into graphics was not successfull.

---
DOS-u-akbar!

> Roberto Perotti (iw2evk) wanted me to share this here for you guis:
> http://sourceforge.net/projects/lodepaint/

got 2 mails about 2 more:

http://ubrowser.com/ (MozillaFirefox-2.xx based browser ???)

http://gigi.nullneuron.net/comp/picaxo/ (IRAN-View clone ???)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

I made a new test on my second machine with dualboot FreeDOS - Windows98.
(test made in FreeDOS but PATH variable set to cover D:\windows\system)

Now the Lodepaint WORKED.
However after init screen I got crash when loading some plugin from .\Pluggins\ subdirectory. So I deleted this plugin and then it worked.

The reaction on mouse movement is slow but the image manipulations are OK (area filling, blurring the image, etc.).
I was able to SAVE the image but I had to go into Settings in upper menu and check off the "use native OS load/save dialog". After that it works but I am not able to browse the directories tree and I was limited to root C:\
However i successfully created the C:\test1.png

---
DOS-u-akbar!

This question probably requires it's own topic, but...

Is there a C/C++ API for HX libs usable with DJGPP and/or OWatcom. Would it be possible to compile some of the WIN32 libs or software natively (for HX)? Would it be possible to use some WINE/ReactOS sources?

Just brainstorming. Sorry if I'm out of place in this topic. Couldn't hold out the question because there might be an answer.

> Would it
> be possible to compile some of the WIN32 libs or software natively (for
> HX)? Would it be possible to use some WINE/ReactOS sources?

I think that most win32 libs depends more or less on WinAPI and maybe windows kernel functions that has not equivalent under DOS, DJGPP whatever. So it's task for HX to emulate this API, instead you would have to static-link a half of Windows/ROS/Wine code to make it work...

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

> This question probably requires it's own topic, but...
>
> Is there a C/C++ API for HX libs usable with DJGPP and/or OWatcom. Would it
> be possible to compile some of the WIN32 libs or software natively (for
> HX)? Would it be possible to use some WINE/ReactOS sources?
>
> Just brainstorming. Sorry if I'm out of place in this topic. Couldn't
> hold out the question because there might be an answer.

I didn't want to answer because I'm not totally familiar with it. I was hoping Japheth would explain. Well, here goes nothing!

There is some C library support in HXDEV for PE (Win32 API?) stuff in DOS. It too complicated to understand (by me) fully, but check HXDEV*.ZIP's LIB/ and LIBOMF/ subdirectories (e.g. static Win32 emulation libs: dkrnl32s.lib, dadvapis.lib, dgdi32s.lib, duser32s.lib).

I assume that's what you meant. If not, be more specific which apps or what you want to compile. (See OWSUPP/readme.txt concerning "hxdos" and "hxnts" targets.)

About UBROWSER ( web-kit based ??) I'd test with HX : I'd "give it step by step" the required .dll but it stopped on the nspr4.dll ( I'd take from XP) "cannot resolve import... cannot load PE file.."
I'd test ubrowser with XP = not so bad but deprived download files....
..by the way : remember OWB ( origyn webkit browser)? It worked with HX ;
it's no longer supported/developed by 3-4 years but I confess sometimes I still use OWB with HX when I want to examine a web page in a whole vision and it works well enough ( example = I cannot see the download link of dugplay in "Mediafire" web page [see "announce" in 16.6.2013] with Arachne or Dillo but I can with OWB (I know: no download, no bookmark etc...)
And at the present (I suppose) OWB is still the only win32 browser working with HX -
Anyone is still working on OWB?
regards
andrea

> @rr : could you please send a (new or old) PWD to Roberto
> Perotti AKA iw2evk so that he doesn't have to use other people
> for posting here?

I unblocked Roberto's account today. I also answered his private e-mail.

---
Forum admin

Hi at all,
unfortunly the site for QWB it's closed, so i suppose nobodody have a copy of source of OWB foer win to modify..
I've found a possible web broser candidate : Netsurf webbroser, a SDL based project.
The binaries for win from here :

http://ci.netsurf-browser.org/builds/windows/

I've make some test , and apart some trobles with winsock on Hx , may be working with some little mod's.
I hope someone want to try to patch the binaries/modify the source

Have a nice day
Roberto

> About UBROWSER ( web-kit based ??) I'd test with HX : I'd "give it step
> by step" the required .dll but it stopped on the nspr4.dll ( I'd
> take from XP) "cannot resolve import... cannot load PE file.."
> I'd test ubrowser with XP = not so bad but deprived download files....
> ..by the way : remember OWB ( origyn webkit browser)? It worked with HX ;
> it's no longer supported/developed by 3-4 years but I confess sometimes I
> still use OWB with HX when I want to examine a web page in a whole vision
> and it works well enough ( example = I cannot see the download link
> of dugplay in "Mediafire" web page [see "announce" in 16.6.2013]
> with Arachne or Dillo but I can with OWB (I know: no download, no bookmark
> etc...)
> And at the present (I suppose) OWB is still the only win32 browser
> working with HX -
> Anyone is still working on OWB?
> regards
> andrea

Only AmigaOS4 port had some more progress, but still, no new version since 2011.

This might be a source code backup:
https://code.google.com/p/owbwebkitskia/source/browse/trunk

> > Would it
> > be possible to compile some of the WIN32 libs or software natively (for
> > HX)? Would it be possible to use some WINE/ReactOS sources?
>
> I think that most win32 libs depends more or less on WinAPI and maybe
> windows kernel functions that has not equivalent under DOS, DJGPP whatever.
> So it's task for HX to emulate this API, instead you would have to
> static-link a half of Windows/ROS/Wine code to make it work...

I tought as HX already emulates this API, there might be a way to make this emulated API public. What I mean is to compile a win32 API program using (already existing) HX win32 API emulation using a native DOS compiler.

Not sure if that is possible, but if it was - there would be possible to compile at least some win32 API apps to native DOS executables (that require or embed HX - not sure how that would work). :)

> > This question probably requires it's own topic, but...
> >
> > Is there a C/C++ API for HX libs usable with DJGPP and/or OWatcom. Would
> it
> > be possible to compile some of the WIN32 libs or software natively (for
> > HX)? Would it be possible to use some WINE/ReactOS sources?
> >
> > Just brainstorming. Sorry if I'm out of place in this topic.
> Couldn't
> > hold out the question because there might be an answer.
>
> I didn't want to answer because I'm not totally familiar with it. I was
> hoping Japheth would explain. Well, here goes nothing!
>
> There is some C library support in HXDEV for PE (Win32 API?) stuff in DOS.
> It too complicated to understand (by me) fully, but check HXDEV*.ZIP's LIB/
> and LIBOMF/ subdirectories (e.g. static Win32 emulation libs: dkrnl32s.lib,
> dadvapis.lib, dgdi32s.lib, duser32s.lib).
>
> I assume that's what you meant. If not, be more specific which apps or what
> you want to compile. (See OWSUPP/readme.txt concerning "hxdos" and "hxnts"
> targets.)

That. Thanx. :)

For example, you could compile SDL *for* HX and then compile "your favorite SDL app" with that, making it run natively on DOS (using HX API) and eliminating "msvcrt" problems.

> For example, you could compile SDL *for* HX and then compile "your favorite
> SDL app" with that, making it run natively on DOS (using HX API) and
> eliminating "msvcrt" problems.

That way you also eliminate version problems and compatibility issues with the win32 binaries compiled with the different versions of win32 compilers. Also you wouldn't depend on the version of SDL library used - you already know it's HX compatible (as it was compiled using it's API emulation).

That. :)

> Not sure if that is possible, but if it was - there would be possible to
> compile at least some win32 API apps to native DOS executables (that
> require or embed HX - not sure how that would work). :)

I though you think the second case that would require "static HX linking"/embedding HX. For the first case you can simply replace default PE stub of any win32 program to launch HX under DOS. This doesn't break windows comparability just replace the useless message inform you that it requires Windows when launched under DOS.

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