Re: [Freedos-devel] Suggestions Many future DOS Flavors and uses...

[Chelson a via Freedos-devel]

Why make anything then? Lol. It doesn't matter how trivial if it's fun the
chances are someone else is keen to do it.

Bear in mind that an x86 watch would be more funny than practical.

Psu on your back with a bunch of cables running up your arm lol.

Cyberpunk 1996 kinda look to it.

On Tue, 2 July 2024, 10:08 pm Liam Proven via Freedos-devel, <
freedos-devel@lists.sourceforge.net> wrote:

> On Tue, 2 Jul 2024 at 03:22, Richard Stoltenberg via Freedos-devel
>  wrote:
> >
> > use Freedos for a wrist watch os.  The samsung watch hardware has alot
> of power.
>
> Pointless. DOS is an x86 OS. There are no x86 smartwatches. You'd need
> to run it in an emulator which would squander the very limited battery
> life. No point.
>
> > BigDOS: windows 98 ran on a DOS.
>
> So what?
>
> > Port to Amiga, and c64
>
> No. Amiga uses 68000 and that's dead. DOS is not a portable OS and it
> can't be moved from x86 to anything else. It depends on and uses the
> segmented memory architecture of x86-16 and it would be impossible as
> well as pointless on anything else. The point of DOS is that it's very
> simple and primitive. It would be much much *worse* than AmigaOS.
>
> DOS was based on the design of CP/M. CP/M existed for 68000: CP/M-68K.
> Go resurrect that: the sources are there.
>
> https://www.mega-micros.co.uk/cpm-68k.htm
>
> Atari TOS was loosely descended from DR-DOS and CP/M-68K. EmTOS is a
> modern version. It already runs on Amiga.
>
> https://github.com/emutos/emutos/blob/master/doc/readme-amiga-rom.txt
>
> C64 is an 8-bit architecture. DOS is 16-bit. Also impossible and pointless.
>
> But there is a kinda-sorta CP/M for 6502 now.
>
> https://github.com/davidgiven/cpm65
>
> Channel your enthusiasm into learning the history! You are missing a
> lot of the bigger picture here. Go read and learn.
>
>
> > BIOSFreeDOS/UEFI Support/questions: supposedly UEFI runs on top of DOS.
>
> No it does not.
>
> UEFI uses FAT32 but not DOS and it's incompatible with any and all x86-16
> OSes.
>
> > BFreeDOS: feel free to use the name idea.  FreeDOS for the blind and
> others.
>
> Already a thing. Ask Karen Llewellyn.
>
> > Blynix - is a web browser for the blind using text, and is available for
> multiple platforms. It requires some configuration and has support for
> https. The g key can be used to type in a web address.  The browser uses a
> config file.
>
> DOS is a terrible choice for this.
>
> --
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> IoM: (+44) 7624 277612: UK: (+44) 7939-087884
> Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
>
>
> ___
> 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] 16-bit Windows development

[Chelson a via Freedos-devel]

yes of course. Well aware.

It would be funny to see Microsoft Sue someone for a 30 year old os shell
though. Lol.



On Tue, 11 June 2024, 9:43 am Steve Nickolas via Freedos-devel, <
freedos-devel@lists.sourceforge.net> wrote:

> On Tue, 11 Jun 2024, Chelson a via Freedos-devel wrote:
>
> > Yes obviously the legal side of things prevents using that code, it's
> also
> > a good reference of how it all works and you could build from scratch.
>
> Do that and you'll be sued into the ground faster than you can say
> "Chinese wall".
>
> -uso.
>
>
> ___
> 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] 16-bit Windows development

[Chelson a via Freedos-devel]

No, win11 is not what I'm suggesting. Far from it.

Im talking about the recently leaked 3.x code as a reference to start an
opensource version of the Windows 3.1 shell.

I played around with the react os code about 15 years ago to test out what
the cmd was capable of doing for running dos applications and some ran fine
and others not.

Anyway it's too much of a job for anyone person to do and a lot of work to
start a new opensource api for a very limited market.

On Tue, 11 June 2024, 9:52 am Kirn Gill via Freedos-devel, <
freedos-devel@lists.sourceforge.net> wrote:

> > Are you sure it would be easier?
>
> For the most part. You really only need 286 Standard Mode for basic
> "completeness". Obviously 386 Enhanced Mode is needed too, but not entirely
> required (what about contemporaneous users of Windows 3.1 that only had a
> 286?)
>
> > Especially reimplementing Win 3.1 enhanced mode would be very hard to
> implement, I think. To my knowledge, we do not have a working open source
> DOS task switcher yet, capable of switching between "multiple DOS
> sessions", or is there one? To me, this the "main feature" of Windows 3.1 :)
>
> What part of "386 Enhanced" mode are we needing here? The 32-bit KRNL386?
> It'll run under any DPMI host and give you "386 Enhanced Mode". However,
> what most people really want here is the second half: The Virtual Machine
> Manager, which is a VM86 manager and a DPMI host. "386 Enhanced Mode" is
> then just KRNL386 running inside of the "System VM", which is just another
> DOS box, but with special treatment (it can call certain APIs via interrupt
> vector that do nothing on any other DOS box the VMM manages.) If you can do
> hardware-based task switching, manage Virtual 8086 Mode instances, and
> intercept/reimplement interrupt-based APIs - many DOS calls are actually
> handled by VMM and it's loaded VxDs, not DOS itself - then you've got a
> good shot at reimplementing VMM itself.
>
> VMM lives in WIN386.EXE, which is itself a DOS loader for VMM and a
> collection of VxDs. I'm working on a tool in my spare time to do something
> akin to "readelf" but for MZ/NE/LE/PE. It's not complete by any measure,
> but it can read WIN386.EXE and dump out the table of included VxDs. The
> tool can be found at https://github.com/segin/readexe
>
> In Windows 3.1, the DOS stub in Windows 3.1 is about 14k, and the VMM
> itself is about 1.5k larger. Running "readexe" on WIN386.EXE from Windows
> for Workgroups 3.11 yields the following:
>
> DOS executable with magic:  MZ (0x5a4d)
> Number of executable pages: 0x0036 (27136+ bytes)
> Size of final page: 0x (0 bytes)
> Total code size:0x6a00 (27136 bytes)
> Total relocation entries:   0x000f
> Header size in paragraphs:  0x0020 (512 bytes)
> Minimum heap in paragraphs: 0x1400 (81920 bytes)
> Maximum heap in paragraphs: 0x (1048560 bytes)
> Minimum memory to load: 109056 bytes
> Initial CS:IP (entrypoint): :10ef
> Initial SS:SP (stack):  06a0:0400
> Checksum:   0x2f24
> Relocation table offset:0x0040
> Overlay:0x
>
> MZ EXE relocaton table
> Number of relocations: 15
>   [0] :08cb
>   [1] :0f97
>   [2] :0fb3
>   [3] :10f9
>   [4] :19ff
>   [5] :1acd
>   [6] :2262
>   [7] :24c8
>   [8] :260d
>   [9] :279f
>   [10] :2827
>   [11] :2f93
>   [12] 0348:1def
>   [13] 0348:1df3
>   [14] 0348:1df7
> Offset to next header:  0x6c00
>
>
> W3 Executable header found at offset 0x6c00
> VxD Module Table:
>ID   Name  Offset  Size   (dec)
> --
>   [00] "WIN386  " 0x7000  0x3b8b (15243 bytes)
>   [01] "INT13   " 0x00022400  0x021b (539 bytes)
>   [02] "WDCTRL  " 0x00023c00  0x02aa (682 bytes)
>   [03] "VMD " 0x00027400  0x0308 (776 bytes)
>   [04] "VPD " 0x00029c00  0x029a (666 bytes)
>   [05] "VWC " 0x0002c400  0x0220 (544 bytes)
>   [06] "DOSNET  " 0x0002ec00  0x023f (575 bytes)
>   [07] "VNETBIOS" 0x00031400  0x0410 (1040 bytes)
>   [08] "EBIOS   " 0x00035400  0x01be (446 bytes)
>   [09] "VDDVGA  " 0x00037c00  0x0dbf (3519 bytes)
>   [0a] "VKD " 0x00042800  0x090c (2316 bytes)
>   [0b] "VPICD   " 0x00047400  0x0833 (2099 bytes)
>   [0c] "VTD " 0x0004a400  0x052d (1325 bytes)
>   [0d] "REBOOT  " 0x0004c800  0x0257 (599 bytes)
>   [0e] "VDMAD   " 0x0004e400  0x0790 (1936 bytes)
>   [0f] "VSD " 0x00051800  0x019b (411 bytes)
>   [10] "V86MMGR " 0x00053400  0x0f99 (3993 bytes)
>   [11] "PAGESWAP" 0x0005fc00  0x038f (911 bytes)
>   [12] "DOSMGR  " 0x00062400  0x17e8 (6120 bytes)
>   [13] "VMPOLL  " 0x0006e400  0x0224 (548 bytes)
>   [14] "WSHELL  " 0x0006fc00  0x0daa (3498 bytes)
>   [15] "BLOC

Re: [Freedos-devel] 16-bit Windows development

[Chelson a via Freedos-devel]

Yes obviously the legal side of things prevents using that code, it's also
a good reference of how it all works and you could build from scratch.

If you just want to make programs just use visual basic like I did back in
the day to make new programs.. Quite limited by today's standards.

Or take the fltk source code which already is basically a window
manager/shell that has dillo and other apps built for it?

On Sun, 9 June 2024, 9:50 am Ralf Quint via Freedos-devel, <
freedos-devel@lists.sourceforge.net> wrote:

> On 6/3/2024 2:53 PM, Kirn Gill via Freedos-devel wrote:
> > Does anyone here have any experience with systems programming for
> > 16-bit (DOS-based) versions of Windows?
> >
> > Do you know of a good forum?
> >
> > Has anyone attempted to clone Windows 3.x in the same way as ReactOS?
>
> No. And it is doubtful that anyone ever seriously tried. ReactOS started
> as a Windows 95 clone and was (and kind of still is) always a moving
> target ever since. And not sure if anyone would ever try and pick this
> up as a task, too many programmers these days are too lazy to be
> bothered to develop anything for 16bit, you can even see this in the
> contributions for FreeDOS
>
>
> Ralf
>
>
>
>
> ___
> 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] 16-bit Windows development

[Chelson a via Freedos-devel]

Yes, get the official code. The current kernel has the 3.51 NT kernel.

On Tue, 4 June 2024, 9:54 am Kirn Gill via Freedos-devel, <
freedos-devel@lists.sourceforge.net> wrote:

> Does anyone here have any experience with systems programming for 16-bit
> (DOS-based) versions of Windows?
>
> Do you know of a good forum?
>
> Has anyone attempted to clone Windows 3.x in the same way as ReactOS?
>
> --
> Kirn Gill II
> Mobile: +1 813-300-2330 <+18133002330>
> VoIP: +1 813-704-0420 <+18137040420>
> Email: segin2...@gmail.com
> LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6
> ___
> 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] Thinking about FreeDOS 2.0

[Chelson a]

Unless something huge changed about freedos I think “1.4” should be the next 
version apposed to a jump to 2.0 and while its nice to update packages to the 
latest versions what is the problem developers are trying to fix? What is the 
roadmap?

Like its been a while since ive actually used freedos and while I have been 
working on a new version of Aura GUI here and there over the past few years it 
has always maintained a roadmap. The next version features a graphical sdk that 
can generate c code, read c code and can test your apps in widget and apps can 
access the watt32 tcp library.

New features?
The ability to "apt-get” packages should allow users to connect to the internet 
and download the packages & save space for the official distro. 

Something else to consider is for many older systems that have serial ports I 
think wifi modems (esp8266 modules etc) should become a standard.

An easy SDK, how will freedos bring new users in to keep developing for the 
platform?? A working djgpp (or whatever) environment from boot that can 
download sources and compile small applications.

dead seas is an its game which will be playable online on the “k-world” game 
service which includes DOS systems. K world is not being developed by me but 
aims to be like a “steam” for retro games that allows you to chat, download 
games etc..

For me freedos has not really developed past being a dos clone, many people 
make great contributions towards freedos but it feels like the scene is ageing 
and loosing momentum.

making freedos an online os with services, for education for coding… ludumdare 
kind of developing contests…etc make freedos a community 

 

> On 3 Mar 2022, at 4:13 pm, Jim Hall  wrote:
> 
> On Sun, Feb 20, 2022 at 4:16 PM Jim Hall  wrote:
> [..]
>> I'm sure we'll want to discuss "1.4" or "2.0" or whatever version
>> comes after 1.3. (I can start a new conversation next week to talk
>> about that.)
> 
> 
> Now that FreeDOS 1.3 has been out for a little while, I wanted to
> start thinking about what comes next. Let's use this thread to discuss
> it.
> 
> What would you like to see changed or added (or removed) in the next
> distribution?
> 
> My top three ideas:
> 
> 
> 1. Move to a "rolling release"
> 
> It's taken several years* to release a new version of FreeDOS. Yes,
> DOS is pretty stable, so we don't need a new distribution very often
> anyway. But for many folks, the new official distribution is the only
> way they get the updated tools (most people don't download individual
> tools to update a running FreeDOS system.)
> 
> *Not counting Release Candidates, the last few releases were:
> 1.0 (2006) - 1.1 (2012) - 1.2 (2016) - 1.3 (2022)
> 
> I think it would be interesting to set up a system that builds a new
> FreeDOS "test" distribution whenever we update packages on the FreeDOS
> Files Archive at Ibiblio. That doesn't need to be a new build every
> night, but maybe every month.
> 
> I think these distributions would come in only two versions: a "full"
> FreeDOS that looks like the LiveCD (see also #3 below) and a "mini"
> FreeDOS that contains just the FreeDOS "Base" packages, without source
> code. (The "mini" should be very tiny, and basically the same as a
> "floppy" FreeDOS install .. I guess "floppy" is a third distro
> version, but I think it could be derived from the "mini.")
> 
> Folks can try out the new "test" distribution and always be on the
> latest version. When things are stable, we can choose a "snapshot"
> that works well, and make that the next official distribution. That
> might happen on some interval (every 6 months? 12 months?).
> 
> 
> 2. Simplify FreeDOS
> 
> The FreeDOS distribution has grown. We've added a bunch of packages
> over the years, and FreeDOS has become quite large. We added the
> BonusCD (634MB) because we couldn't fit everything on the LiveCD
> (401MB).
> 
> Over time, we added some things because they were useful at the time,
> but we added others because they were a neat thing to have. Are these
> useful in 2022? I think we should re-evaluate what's in FreeDOS, and
> trim down what we include. DOS should not be that big.
> 
> For example: I think the Unix-like utilities should go. I thought the
> Unix-like tools might generate interest from new developers, but I
> think the Unix-like tools just confuse things and make FreeDOS look
> like a "mini Linux." Let's just be DOS.
> 
> I think we can also remove some packages from Editors, Archivers, and
> Utilities. We might remove all of the Graphical Desktops, since these
> are of limited usefulness and not maintained anyway.
> 
> What packages to keep and remove is probably a larger discussion that
> we could move into a dedicated thread.
> 
> The full list of packages (LiveCD and BonusCD) is in the FreeDOS 1.3
> report document:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/report.html
> 
> 
> 3. Make LiveCD the default
> 
> We know from the 2021 user survey** that a lot

Re: [Freedos-devel] New Old Timer reporting :-)

[Chelson a]

I am working on these esp01/8266 with at commands from dos you can connect to a 
wifi in dos and other retro machines. This should be a viable option for 
freedos.

https://www.instructables.com/Getting-Started-With-the-ESP8266-ESP-01/ 


Thoughts?

> On 2 Dec 2020, at 9:26 am, Danilo Pecher  
> wrote:
> 
> wireless, I don't even go there, it's an iwi that need proprietary Intel 
> firmware - no sale. 
> 
> No, the machine is a geriatric Compaq Nx8220 and the NIC in question is a 
> Broadcom Ethernet card. BCM5751M.
> 
> On Wed, 2 Dec 2020 at 00:09, Eric Auer  > wrote:
> 
> Hi!
> 
> > laptop is 15 years old, and even that has hardware that is 'too new'
> 
> You mean wireless?
> 
> > I think you're asking two implicit questions here: a) Should we abandon
> > 16 bit hardware as nobody has any, which would mean FreeDOS goes 32bit.
> 
> No. Things which work well with 640k can AND should stay 16 bit :-)
> 
> Just relax that requirement for things which work BETTER in 32 bit.
> 
> > why FreeDOS?
> 
> Because you can :-) And because many DOS apps already exist.
> 
> > Not trying to get too philosophical here
> 
> Who knows ;-)
> 
> > FreeDos needs to find its main purpose and then adjust course
> 
> It already has a purpose - the question is what you want to change.
> 
> Regards, Eric
> 
> 
> 
> ___
> 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] Simplifying FreeDOS

[Chelson a]

Why not have a simple floppy that can install the system via internet
connection?

Base cd, extras cd and boot disk with internet install?



On Sun, 8 Nov 2020 at 05:37, Mark Olesen  wrote:

> Why not have a minimal install iso.  Then have separate additions iso
> for each category? Could the install handle that?
>
> On Sat, Oct 24, 2020 at 2:39 PM Jim Hall  wrote:
> >
> > Some of us had this conversation a while back and I wanted to bring it
> up again on the list.
> >
> > MS-DOS was a small operating system. MS_DOS 5 and 6 fit on a few 1.44MB
> floppy disks.
> >
> > We always intended FreeDOS to not just replace but enhance DOS. FreeDOS
> is "MS-DOS plus more." To make clear what's part of the "core" of FreeDOS,
> we have the "Base" package group. These packages replicate the behavior and
> functionality of MS-DOS. But we also have a lot of other packages that add
> new functionality to FreeDOS, and we put these programs in other package
> groups like "Editors" (additional editors) and "Devel" (compilers,
> assemblers, and other development tools).
> >
> > Over time, FreeDOS has grown to include lots of interesting programs.
> The FreeDOS 1.2 and 1.3RCx distributions are very big.
> >
> > As we look to the next FreeDOS 1.3 Release Candidate, I think we should
> consider removing some packages from the FreeDOS distribution.
> >
> > To be clear: I am not suggesting deleting packages or programs from the
> FreeDOS archive at ibiblio. There's lots of useful and interesting programs
> there. But I don't think we need to include everything in the FreeDOS
> distribution.
> >
> > Here are my thoughts from the FreeDOS 1.3 package list (wiki)
> >
> > Base
> > Keep everything
> >
> > Archivers
> > Do we really need all of those archivers? For example, who needs Zoo
> these days? My suggestions:
> > 1. Move bz2, gzip, and tar to the "Unix" group - these are replicas of
> Unix tools
> > 2. Keep zip, unzip, p7zip
> > 3. Remove the other packages: 7zdec, arj, cabext, lpq1, lzip, lzma,
> lzop, zoo
> >
> > *Note that p7zip can unpack a ton of other file formats, so we don't
> need these other archivers anyway.
> >
> > Boot Tools
> > *I don't have any strong feelings here. What are your thoughts?
> >
> > Development
> > Can we pare down the list a bit? We have a lot of packages here, but I
> don't think we need them all. For example, we should include the tools we
> know we'll need to compile the different FreeDOS utilities. I'd also like
> to keep the GCC related packages, and other packages that remain popular.
> My suggestions:
> > 1. Move perl to the "Unix" group
> > 2. Keep BWBasic, the DJGPP packages, FASM, the FBC packages (FreeBASIC
> Compiler) fpc (FreePascal compiler), the GCC-IA16 packages, JWASM, NASM, OW
> (OpenWatcom C Compiler), and UPX
> > 3. Remove bcc (Bruce's C Compiler), euphoria, insight, lua, regina,
> runtime
> >
> > *I think I missed some packages in that list. I don't have a good
> opinion on those. What do you think?
> >
> > Editors
> > Not sure about these. I know there are a few here I'd like to keep:
> > Blocek, Elvis, FED, Freemacs, MSEDIT, pico, Vim
> >
> > *I don't have a good opinion on the other editors in the list. Which
> ones do you think need to stay?
> >
> > Emulators
> > I don't think that these are useful to include in the full distribution.
> These all fall in the general category of "games," anyway. I'd recommend we
> eliminate the entire "Emulators" package group.
> >
> > Games
> > I generally feel that we can add and remove games in the FreeDOS
> distribution on a whim. If a game is interesting and open source, we can
> include it. When a game stops being interesting, or doesn't interest a lot
> of people, we can remove it.
> >
> > *I really enjoy Wing and a few others. I don't have strong opinions on
> the other games. What are your thoughts?
> >
> > Graphical Desktop
> > We added GUIs a long time ago when people were still doing active
> development on OpenGEM, oZone, and Seal. If you've been part of the
> discussion for a long time, you also remember we included a few other
> graphical menus and things that have since fallen out of the distribution.
> I think it's time to look at these GUIs too. My recommendations:
> > 1. PC-GEOS was released as open source software. I haven't followed it,
> but last I checked, they weren't able to compile it (missing libraries, I
> think - requires some rewrites?) If they can get this to compile, I think
> we can include it. If they still can't compile it, then do not include it.
> > 2. Remove SEAL and oZone. These haven't been worked on for a long time,
> and they are still incomplete
> > 3. Keep OpenGEM. It's not under active development, but it's currently
> pretty solid, if plain looking
> >
> > Networking
> > I don't run FreeDOS with a network, so I don't have any opinions on
> these packages. What do you think?
> >
> > Sound
> > I know OpenCP and MPlayer both work fine, because I demo'd them in a
> YouTube video. I don't have any opi