freebasic on win32s

DOS specific questions.
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

freebasic on win32s

Post by Mysoft »

i know this is the DOS forum.... and even that win32s is "windows" in almost all senses... it belongs to win3.11 that was basically over DOS... so if any, it will be relevant mainly for people on this forum... and that's what i'm checking...

i made changes so that freebasic can be compiled for win32s (requires relocations, because theres no address separation), and when compiling with -gen gcc (or any C library) it must use CRTDLL instead of MSVCRT, as well theres many stuff not implemented on win32, mainly security, unicode, directx, opengl, threads, events... so basically everything that exist on win16 is implement on the win32 subset), and its working with latest mingw! (oh and btw theres no CONSOLE on win32s, but output can be redirected to serial, etc.. etc.. i particulary just use OutputDebugString to debug and view on a separate programs, but that means console programs will not have any console, and so programs that does not sleep/flip, are mostly NOT responsive, because win32s over win3.11 require preemptive stuff)... (i actually like that because lol, it teaches you how to improve the overal stability of your program even on win32!)

i used -prefix 32s as option to select that target, and instead of changing freebasic sources, i just made wrappers for the gcc,ld,as to deal with some minor differences as well to remove all the CRT init, etc... that wont work on win32s

so i compiled fbgfx/rtlib to use CRTDLL (yay no _s functions used! :D), and with 386 target, because we dont want ppro instructions on win32s :P

i also "hackplemented" fbgfx for win32s over WinG (only for 8bpp) and it was implemented on top of fbgfx_null backend, without using a thread and requiring manual "flip" to update just like OpenGL, i didnt implemented dirt lines update yet altough i can... but i did something different (and better imo)... when screenunlock is called it will automatically update the screen, but screenunlock can use coordinates of the area to update, so that allows to properly have games that just update small portions, and that would need that speed to work fast (freebasic should had that since day 1... but nobody cared :P)

did proper palette handling for win3.11 where is not possible to have all 256 colors, while the screen is 256, due reserved colors, and trying to use the reserved colors would cause a MASSIVE (90% slowdown), so color 0 is also black and color 255 is always white... but if the palette usage is defined to use the reserved 20 colors (default), it makes sure to ignore those colors, for optimal speed (identity palette)

win3.11 does not have sleep... but win32s implemented sleep... on top of yield but that does not save power!, so i reimplemented sleep, using multimedia timer (only win3.11/not win32s) if delay is < 1/18.2s , otherwise using regular WM_TIMER, and waiting for messages, so the system call the APM functions (on dosbox running on win3.11 with the APM patch you can now have cycles=80000 but just using <500 cycles/ms by using that sleep on a loop that just poll a key)... so for it to work with the multimedia timer the "SlpDLL16.dll" that i made must be on system folder or app folder

likewise win3.11 timer is not very well implemented, so i used toolhelper timer... that poll the PIT to get the "1mhz" accuracy timer... but actually toolhelp just return that as 1000hz tick count... so you get a 1ms accurate timer...

so basically those make timer/sleep on win32s better than on win95/98 even on computers where QueryPerformanceCounter is not avaliable (and sleep on 95/98 was just 18.2hz accurate, so this same sleep replacement WORK! on win95/98 as well.

win3.11 does not allow dynamic screen changes (well not by normal api's), so while its possible to have vesa modes, and regular bios modes to be called, the system is not aware... and on many cases video drivers have bugs and it crashes, corrupting when going back to the normal video mode... so everything on fbgfx is windowed... however fb.GFX_FULLSCREEN works, by using WinG stretchblt that is slower if not hardware accelerated... but works, and also theres a screencontrol to be called to select a scaling... where 2x scale is fast even without the hw acceleration, and it only happens when blitting to the screen, by WinG itself, (which again can be hw accelerated if the card support that), and actually a good amount of cards that support >256 colors on win3.11 ALREADY have hardware accelerated blits!, including the S3 card emulated on dosbox

so if anyone have interest on that, or want more details, or get it for testing, usage, i can provide, (i just didnt released because its a WIP, just because i was doing tests on it... for some other project :)
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

Re: freebasic on win32s

Post by Mysoft »

some screenshots...

Image
Image
Image
Image
Image
Image
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: freebasic on win32s

Post by angros47 »

Impressive! And a pleasant surprise, seeing someone doing a port for Windows 3.1 (in my opinion, Windows 3.x was the best version of Windows, considering what it was able to do with such limited hardware resources).

Too bad that no one ever managed to remake it open source (ReactOS works more like Windows NT than like Windows 3.x)
Knatterton
Posts: 165
Joined: Apr 19, 2019 19:03

Re: freebasic on win32s

Post by Knatterton »

@angros47 You could try redmond3 theme with mint xfce:

https://www.xfce-look.org/p/1016410
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: freebasic on win32s

Post by angros47 »

The theme would just look like windows 3.1, it would still have the system requirements of Linux
Knatterton
Posts: 165
Joined: Apr 19, 2019 19:03

Re: freebasic on win32s

Post by Knatterton »

I have tried this theme yesterday in mint xfce but could not get it to work. "Redmond" works, that is M$ enough to me.

But with wine it is possible to run even original win 3.1 programs as i described in linux section. Anyway, those old programs can only be interesting for short time today, as we have much better stuff now. :-)
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: freebasic on win32s

Post by angros47 »

Knatterton, the redmond theme is totally unrelated with this topic, could you stop mentioning it, please?

I personally find Mysoft's work very interesting, at least as a retrocomputing experiment Also, it allows to redefine the minimal system requirements to run programs compiled with FreeBasic
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

Re: freebasic on win32s

Post by Mysoft »

not to mention that the programs compiled for win32s work on windows 3.11 to windows 10 :P

heh, and yeah even on DOS freebasic gfx have the problem of not working properly inside windows, because of unecessary use of the PIT interrupt, and automatic "full" update, so many of the concepts i "fixed" on win3.11 i also have been using on DOS to overcome fbgfx limits there

and its really fun to see what is possible to be optimized to work under such conditions, like full screen update games are not easy to get speed on win3.11 due lack of certain stuff we can do with vesa... like hardware scrolling (but i guess on a 486 many full screen updates games are doable at 20-30fps with 320x240 WinG 2x scalling to 640x480 (like the FlappyFB screenshot)

now i'm working on translating mbedtls headers to freebasic (manually to keep the documentation), and compile the library to use on win32s, so some https stuff can be done there, despite being a dead OS, but it was so close that i couldnt avoid but doing it :)
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: freebasic on win32s

Post by marcov »

angros47 wrote:Knatterton, the redmond theme is totally unrelated with this topic, could you stop mentioning it, please?

I personally find Mysoft's work very interesting, at least as a retrocomputing experiment Also, it allows to redefine the minimal system requirements to run programs compiled with FreeBasic
It also shows the problem. You can't make use of timers like in still supported versions of Windows. (and for a lot more, like unicode etc).

I would define additional targets for old Windows (win32s and/or win9x). This means that modern and retro users can go ahead without troubling eachother.
Last edited by marcov on Oct 12, 2019 15:06, edited 1 time in total.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: freebasic on win32s

Post by angros47 »

Another challenge could be porting FreeBasic to bare metal (perhaps it could be done by compiling the runtime library using newlib?). This would allow to make FreeBasic programs able to run without operating system.
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: freebasic on win32s

Post by marcov »

angros47 wrote:Another challenge could be porting FreeBasic to bare metal (perhaps it could be done by compiling the runtime library using newlib?). This would allow to make FreeBasic programs able to run without operating system.
Newlib seems to be a glibc for minimal systems. IOW mostly Linux. I don't see any indications that it is for "bare metal".
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

Re: freebasic on win32s

Post by Mysoft »

You can't make use of timers like in still supported versions of Windows. (and for a lot more, like unicode etc).
actually you can... is just freebasic method that didnt used multimedia timers for win95/98, and... using multimedia timers is possible to make a sleep on win95/98 using an event.... (so a sleep with accuracy better than what you would get even on XP (that is 2ms)) and on win32s is the same thing... but since win32s does not have EVENTS... all stuff that would normally use event... use MESSAGES (so there you need to PostMessage from an interrupt, and then use GetMessage() to get just the ONE message that was posted)

and so those methods work even on modern NT... (altough obviously one would want to have different codepath... like MMX not MMX or fbgfx :P)
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: freebasic on win32s

Post by marcov »

The point is that you can't do things like you normally do, and what internet recommends. This complicates things for people mostly working on newer windows. Just like any Windows code after 2000-2005 will probably call -W functions a lot.

Things like that are basically behind the advise to not add to the win32 target, but rather split it in (multiple?) old and new.
srvaldez
Posts: 3373
Joined: Sep 25, 2005 21:54

Re: freebasic on win32s

Post by srvaldez »

@Mysoft
looks really nice, what screen resolution are you using on DOSBox?
Mysoft
Posts: 836
Joined: Jul 28, 2005 13:56
Location: Brazil, Santa Catarina, Indaial (ouch!)
Contact:

Re: freebasic on win32s

Post by Mysoft »

marcov wrote:The point is that you can't do things like you normally do, and what internet recommends. This complicates things for people mostly working on newer windows. Just like any Windows code after 2000-2005 will probably call -W functions a lot.
Things like that are basically behind the advise to not add to the win32 target, but rather split it in (multiple?) old and new.
good... because you shouldnt simple do what internet recommends without reasoning first... the last thing you want is to code like a genius for no good reason... and even that unicode is ok in some cases, its not mandatory, and theres always utf-8 that is what should be used... and then just the final conversion can be routed appropriatelly having more benefits than wasting 2 bytes per char, among other stuff, that exist for comoddity and are not really great... so my point is... that is not unique to win32s vs "modern", because if you can have stuff without requiring new stuff you should do that.. instead of being a capitalist slave... but either way that is not the focus of this post... and i shouldnt even have to say such stuff... theres a reason i posted on DOS forum instead of WINDOWS one... because the mentality of DOS people are the one that understand that...
Last edited by Mysoft on Oct 13, 2019 22:08, edited 2 times in total.
Post Reply