Re: [Freedos-devel] New packages for future releases

[Johnpaul Humphrey]

I second the OpenGEM sentiment. One of the things that makes DOS special to
me, is the simplicity, both of the API, and the usage. Lack of multitasking
is a plus for me, not a minus. (IIRC GEM supports some multitasking
though.) GEM does seem to have that simple, RAW, feel, and that's a good
thing IMHO.

I would probably not be too interested in a Windows 3.x clone, and I am
told that a lot of DOS admins hated it in the day, but it seems to fit the
spirit of the project more than oZone and seal, IMHO.
It still won't beat GEM though. :)

On Sun, Dec 27, 2020 at 3:07 PM Ralf Quint  wrote:

> On 12/27/2020 11:10 AM, Jim Hall wrote:
>
>
> The challenge we've had is lots of developers have wanted to create a GUI
> for FreeDOS, but then they get halfway through building one before they
> realize it's a lot of work. And then the project gets dropped. That leaves
> us with things like SEAL and oZone that look cool - until you look more
> closely and find a bunch of features that don't work. Or it hogs memory. Or
> whatever. And that brings us to the conversation we started here some weeks
> ago about removing some stale packages, like SEAL and oZone. I don't want
> to get into another situation like that.
>
> Well, that is the problem with all of those GUI attempts. Some people have
> grand ideas and start to create some nice colored pictures but none of them
> is seriously thinking about (before they start coding!) on all the basics
> "behind the scenes", to make things really work and being useful.
> And when you point this out to them, they quickly get all defensive and
> pissy...
>
> IMHO, anyone who is REALLY interested to get  a working GUI for FreeDOS
> working, should much rather looking into participating in getting (Open)GEM
> a little bit more up to date.
>
> Ralf
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_6282456411182112900_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>


-- 
Johnpaul T. Humphrey
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[tom ehlert]

> And that was my thinking behind it. Writing yet another nondescript
> GUI would be sort of pointless.
+1

> The main strength of FreeDOS is its
> ability to keep legacy software alive. But by definition there's no
> legacy software available for a GUI that's written in 2020.
+1

> Getting
> close to a free Windows 3 clone however would be a perfect
> continuation of a project that keeps legacy stuff around.
+-0

(almost) no one is using Windows 3.1 programs.
and if, they have a running Windows 3.1 machine, or running it happily
on a 32 bit Windows box.

this was different when when FreeDOS was born.

> And more
> importantly, with the wine project there is already a solid
> foundation on which such a project could be based. 
nope. (I'm not a wine expert, and I'm probably oversimplifying here)

wine does very little on it's own, and mostly translates Windows calls
PutPixel(X,Y,color), DrawLine(), DrawBoxInTransparency(), PlaySound()
into Linux equivalents.
not trivial, but the main work (driver loading, multitasking,...) is still
done in the linux kernel.

lastly:

DOS kernels are ~100 K code, that was extremely well reverse
engineerd, multiple books existed about documented and undocumented
features of MSDOS, and made it possible that several alternatives
existed.
  MSDOS
  DRDOS
  PTS-DOS
  ROMDOS

and even single person project were able to create (lousy) MSDOS clones
like Pat Villanis FreeDOS kernel and Mike Podanoskis RXDOS.

the FreeDOS project was only possiible, and mostly successful, because
it started with an existing kernel. Even then it took ~8 years
(1994-2002) to make a stable, bugfree MSDOS clone.




now realize that

  a) Windows 3.0 is at least an order of magnitude bigger then DOS.
 more code needs more time and/or programmers to write.

  b) Windows 3.0 is much less well documented then MSDOS. makes bug
 finding more complicated. fortunately programmers used
 undocumented stuff much less then in DOS, but some still did.
 remember complains by externel companies (WordPerfect) complain
 that MS programmers used undocumented (secret) stuff, giving them
 an advantage over external programmers.

  c) you won't find a single programer who will spend the next 5 years
 for free to create something as awful as Windows 3.1.

Tom





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Danilo Pecher]

Hi

Ralf makes a very interesting and important point here, especially as it
reminds me of my idealistic and somewhat overconfident self from 1993. Like
many people back in the day I thought I was a l33t hax0r after three years
of dabbling with Turbo-Pascal, Turbo-C and even some assembler. So,
naturally, I started to make grand plans to write a proper GUI for DOS.
Sadly, those grand plans consisted of starting up the IDE and get cracking.
Things like proper planning, defining interfaces - in my 1993 delusions of
grandeur that was for wimps. Needless to say; I went very fast, very
straight, nowhere when it became apparent that such an undertaking is, to
use a technical term, a s**tload of work.

And that was my thinking behind it. Writing yet another nondescript GUI
would be sort of pointless. The main strength of FreeDOS is its ability to
keep legacy software alive. But by definition there's no legacy software
available for a GUI that's written in 2020. Getting close to a free Windows
3 clone however would be a perfect continuation of a project that keeps
legacy stuff around. And more importantly, with the wine project there is
already a solid foundation on which such a project could be based.

Cheers, Danilo

On Mon, 28 Dec 2020 at 00:08, Ralf Quint  wrote:

> On 12/27/2020 11:10 AM, Jim Hall wrote:
>
>
> The challenge we've had is lots of developers have wanted to create a GUI
> for FreeDOS, but then they get halfway through building one before they
> realize it's a lot of work. And then the project gets dropped. That leaves
> us with things like SEAL and oZone that look cool - until you look more
> closely and find a bunch of features that don't work. Or it hogs memory. Or
> whatever. And that brings us to the conversation we started here some weeks
> ago about removing some stale packages, like SEAL and oZone. I don't want
> to get into another situation like that.
>
> Well, that is the problem with all of those GUI attempts. Some people have
> grand ideas and start to create some nice colored pictures but none of them
> is seriously thinking about (before they start coding!) on all the basics
> "behind the scenes", to make things really work and being useful.
> And when you point this out to them, they quickly get all defensive and
> pissy...
>
> IMHO, anyone who is REALLY interested to get  a working GUI for FreeDOS
> working, should much rather looking into participating in getting (Open)GEM
> a little bit more up to date.
>
> Ralf
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_4749868332659970652_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Ralf Quint]

On 12/27/2020 11:10 AM, Jim Hall wrote:


The challenge we've had is lots of developers have wanted to create a 
GUI for FreeDOS, but then they get halfway through building one before 
they realize it's a lot of work. And then the project gets dropped. 
That leaves us with things like SEAL and oZone that look cool - until 
you look more closely and find a bunch of features that don't work. Or 
it hogs memory. Or whatever. And that brings us to the conversation we 
started here some weeks ago about removing some stale packages, like 
SEAL and oZone. I don't want to get into another situation like that.


Well, that is the problem with all of those GUI attempts. Some people 
have grand ideas and start to create some nice colored pictures but none 
of them is seriously thinking about (before they start coding!) on all 
the basics "behind the scenes", to make things really work and being useful.
And when you point this out to them, they quickly get all defensive and 
pissy...


IMHO, anyone who is REALLY interested to get  a working GUI for FreeDOS 
working, should much rather looking into participating in getting 
(Open)GEM a little bit more up to date.


Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Jim Hall]

On Thu, Dec 24, 2020 at 5:53 PM Danilo Pecher <
danilo.pec...@data-experts.biz> wrote:

> Hi Eric,
>
> The ReactOS/Wine combo was what got me thinking in the first place.
> ReactOS was from the start meant to replicate WIndows NT though, which
> isn't quite what I had in mind, as that isn't quite the 16 bit world
> in which FreeDOS exists. Wine would be a starting point, as that
> definitely has 16 bit remnants, like WING. Back many moons ago I used
> some of that source to port Microprose's Grand Prix manager to SDL
> under Linux.
>
> My idea was more along the line of rebuilding Windows 3.11, Best
> windows ever, even if Jim will probably disagree ;)
>
>
Well, I'm not a Windows 3.x fan, but that doesn't mean others aren't. :-)

The challenge we've had is lots of developers have wanted to create a GUI
for FreeDOS, but then they get halfway through building one before they
realize it's a lot of work. And then the project gets dropped. That leaves
us with things like SEAL and oZone that look cool - until you look more
closely and find a bunch of features that don't work. Or it hogs memory. Or
whatever. And that brings us to the conversation we started here some weeks
ago about removing some stale packages, like SEAL and oZone. I don't want
to get into another situation like that.

But a Win16 implementation for FreeDOS would be interesting. I wouldn't say
No. If you are interested in tackling this, go ahead. Announce new releases
here on freedos-devel. If it runs on FreeDOS, I'll gladly repeat the
announcement on our Twitter and on the website.

(There's no "set in stone" rule for what gets posted as a news item on the
website vs what only gets mentioned on Twitter - but generally, I'll
announce anything on Twitter if it's open source. If the project looks like
it is being consistently updated, and thus not likely to disappear, then
I'll also announce it on the website. I also try to share news items on our
Facebook group too.)

Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Danilo Pecher]

Hi,

Wouldn't you reinvent the wheel with that? 32 bit DOS applications
rely on a DOS extender and run okay that way, and to run 32bit WIndows
applications, well, that's literally one of the purposes of ReactOS.
What got me thinking was when I could no longer run Borland Delphi on
Windows, because 16bit. Up to Windows XP and to a degree Windows 7,
you could still run old win3x (and even most win 2x) applications
natively. In windows 10 that's gone for good, which is why I thought,
with FreeDOS being by far the best platform for legacy software, this
might be something worth looking at.

But maybe that's just last century me ;)

Cheers, Danilo

On Fri, 25 Dec 2020 at 02:35, Mercury Thirteen via Freedos-devel
 wrote:
>
> Just a bit of FYI despite the project being nowhere near ready to go as of 
> yet: there is a small group of us working on moving DOS into the 32-bit realm 
> in the form of the Night Kernel. As part of that journey, we eventually want 
> a compatibility layer to make running Windows 3.x executables possible.
>
>
>
> Sent with ProtonMail Secure Email.
>
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, December 24, 2020 6:52 PM, Danilo Pecher 
> danilo.pec...@data-experts.biz wrote:
>
> Hi Eric,
> The ReactOS/Wine combo was what got me thinking in the first place.
> ReactOS was from the start meant to replicate WIndows NT though, which
> isn't quite what I had in mind, as that isn't quite the 16 bit world
> in which FreeDOS exists. Wine would be a starting point, as that
> definitely has 16 bit remnants, like WING. Back many moons ago I used
> some of that source to port Microprose's Grand Prix manager to SDL
> under Linux.
> My idea was more along the line of rebuilding Windows 3.11, Best
> windows ever, even if Jim will probably disagree ;)
> Cheers, Danilo
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Mercury Thirteen via Freedos-devel]

Just a bit of FYI despite the project being nowhere near ready to go as of yet: 
there is a small group of us working on moving DOS into the 32-bit realm in the 
form of the [Night Kernel](https://groups.google.com/g/night-dos-kernel). As 
part of that journey, we eventually want a compatibility layer to make running 
Windows 3.x executables possible.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, December 24, 2020 6:52 PM, Danilo Pecher 
danilo.pec...@data-experts.biz wrote:

> Hi Eric,
> The ReactOS/Wine combo was what got me thinking in the first place.
> ReactOS was from the start meant to replicate WIndows NT though, which
> isn't quite what I had in mind, as that isn't quite the 16 bit world
> in which FreeDOS exists. Wine would be a starting point, as that
> definitely has 16 bit remnants, like WING. Back many moons ago I used
> some of that source to port Microprose's Grand Prix manager to SDL
> under Linux.
> My idea was more along the line of rebuilding Windows 3.11, Best
> windows ever, even if Jim will probably disagree ;)
> Cheers, Danilo
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Danilo Pecher]

Hi Eric,

The ReactOS/Wine combo was what got me thinking in the first place.
ReactOS was from the start meant to replicate WIndows NT though, which
isn't quite what I had in mind, as that isn't quite the 16 bit world
in which FreeDOS exists. Wine would be a starting point, as that
definitely has 16 bit remnants, like WING. Back many moons ago I used
some of that source to port Microprose's Grand Prix manager to SDL
under Linux.

My idea was more along the line of rebuilding Windows 3.11, Best
windows ever, even if Jim will probably disagree ;)

Cheers, Danilo


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New packages for future releases

[Eric Auer]

Hi Danilo and merry holidays to everybody :-)

> So here's the question: Is there a process to pitch new packages

Just pitch them here. And if they are cool pitch them for our
ibiblio or other repositories of other people on the list :-)
>From there, distro inclusion would be a possible next step.

> a) Has there ever been an attempt at creating a FreeWin?

It is called ReactOS and shares some code with Wine, see there.

Enjoy your holidays and stay safe :-)

Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel