LodePaint (under HX) (Emulation)

> 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.

LodePaint in DOS | source | banned Roberto

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

LodePaint (under HX)

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.

LodePaint (under HX)

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

2 more (under HX, banned Roberto) - remember OWB?

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

2 more (under HX, banned Roberto) - remember OWB?

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 :

2 more (under HX, banned Roberto) - remember OWB?

> 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.

LodePaint (under HX)

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.

LodePaint (under HX)

> 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...

LodePaint (under HX)

> > 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). :)

LodePaint (under HX)

> 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.

LodePaint (under HX)

> 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!

LodePaint (under HX)

> > 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.

LodePaint (under HX)

> 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).