This group is about DOS, not about GEM. This group is about DOS, not DJGPP, 32-bit DPMI hosts aren't DOS.
This group is about DOS, not random compression utilities like ZOO. This group is about DOS, not third-party shells like PGME. This group is about DOS, not boot sector games. You can run DOS programs on an up-to-date Windows 10 with zero add-ons by just using a 32-bit OS build. Why do we need FreeDOS? Does your mouth feel full of foot yet? Arrogant myopia isn't going to go far, kid. Sent from my T-Mobile 5G Device Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Richard Stoltenberg via Freedos-devel <freedos-devel@lists.sourceforge.net> Sent: Thursday, August 8, 2024 2:18:13 PM To: Technical discussion and questions for FreeDOS developers. <freedos-devel@lists.sourceforge.net> Cc: Richard Stoltenberg <rs98...@gmail.com> Subject: Re: [Freedos-devel] 16-bit Windows development If it was leaked then certain people wouldn't legally approve of it. With a $35 monthly MSDN subscription, you had access to it binary for development purposes. Don't know if still available. With wine you can run windows 3.11 programs on Windows 10 and 11. This group is about DOS. On Mon, Jun 10, 2024 at 5:24 PM Chelson a via Freedos-devel <freedos-devel@lists.sourceforge.net<mailto:freedos-devel@lists.sourceforge.net>> wrote: 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<mailto: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: 0x00000000 (0 bytes) Total code size: 0x00006a00 (27136 bytes) Total relocation entries: 0x000f Header size in paragraphs: 0x0020 (512 bytes) Minimum heap in paragraphs: 0x1400 (81920 bytes) Maximum heap in paragraphs: 0xffff (1048560 bytes) Minimum memory to load: 109056 bytes Initial CS:IP (entrypoint): 0000:10ef Initial SS:SP (stack): 06a0:0400 Checksum: 0x2f24 Relocation table offset: 0x0040 Overlay: 0x0000 MZ EXE relocaton table Number of relocations: 15 [0] 0000:08cb [1] 0000:0f97 [2] 0000:0fb3 [3] 0000:10f9 [4] 0000:19ff [5] 0000:1acd [6] 0000:2262 [7] 0000:24c8 [8] 0000:260d [9] 0000:279f [10] 0000:2827 [11] 0000:2f93 [12] 0348:1def [13] 0348:1df3 [14] 0348:1df7 Offset to next header: 0x00006c00 W3 Executable header found at offset 0x00006c00 VxD Module Table: ID Name Offset Size (dec) ------------------------------------------------------ [00] "WIN386 " 0x00007000 0x00003b8b (15243 bytes) [01] "INT13 " 0x00022400 0x0000021b (539 bytes) [02] "WDCTRL " 0x00023c00 0x000002aa (682 bytes) [03] "VMD " 0x00027400 0x00000308 (776 bytes) [04] "VPD " 0x00029c00 0x0000029a (666 bytes) [05] "VWC " 0x0002c400 0x00000220 (544 bytes) [06] "DOSNET " 0x0002ec00 0x0000023f (575 bytes) [07] "VNETBIOS" 0x00031400 0x00000410 (1040 bytes) [08] "EBIOS " 0x00035400 0x000001be (446 bytes) [09] "VDDVGA " 0x00037c00 0x00000dbf (3519 bytes) [0a] "VKD " 0x00042800 0x0000090c (2316 bytes) [0b] "VPICD " 0x00047400 0x00000833 (2099 bytes) [0c] "VTD " 0x0004a400 0x0000052d (1325 bytes) [0d] "REBOOT " 0x0004c800 0x00000257 (599 bytes) [0e] "VDMAD " 0x0004e400 0x00000790 (1936 bytes) [0f] "VSD " 0x00051800 0x0000019b (411 bytes) [10] "V86MMGR " 0x00053400 0x00000f99 (3993 bytes) [11] "PAGESWAP" 0x0005fc00 0x0000038f (911 bytes) [12] "DOSMGR " 0x00062400 0x000017e8 (6120 bytes) [13] "VMPOLL " 0x0006e400 0x00000224 (548 bytes) [14] "WSHELL " 0x0006fc00 0x00000daa (3498 bytes) [15] "BLOCKDEV" 0x00076800 0x0000028e (654 bytes) [16] "PAGEFILE" 0x00079400 0x0000048b (1163 bytes) [17] "VFD " 0x0007c400 0x0000018a (394 bytes) [18] "PARITY " 0x0007dc00 0x00000168 (360 bytes) [19] "BIOSXLAT" 0x0007f400 0x000001b4 (436 bytes) [1a] "VCD " 0x00080c00 0x00000507 (1287 bytes) [1b] "VMCPD " 0x00084400 0x0000021e (542 bytes) [1c] "COMBUFF " 0x00086c00 0x00000211 (529 bytes) [1d] "CDPSCSI " 0x00088400 0x00000155 (341 bytes) [1e] "QEMMFIX " 0x0008ac00 0x000001ac (428 bytes) > Do not forget USER.EXE. To my knowledge, much of the windowing and controls > stuff is implemented in it. It's particular implementation isn't described much in any of the texts that I've read, short of discussion of how USER32.DLL mostly just thunks to USER.EXE in Windows 3.1/95/98/ME (3.1? Win32s, remember?). I'm not forgetting it, per se, I just have no particular books to recommend for it other than just regular programming texts focusing on the public API (e.g. Programming Windows by Charles Petzold) > Perhaps as a "proof-of-concept" one could restrict to a real mode only, > single program runtime facility. There, things like the dynamic linker and > loader for NE executables / DLLs etc. and other basic KERNEL, GDI and USER > functions could be implemented and tested. That's actually one of the initial goals. See if we can cook up Windows 1.0x in the interim. That requires most of the groundwork needed to properly scaffold such a project. > Thanks for the book references! Here's some more that'll be quite useful in this sort of endeavor: Unauthorized Windows 95: A Developer's Guide to Exploring the Foundations of Windows "Chicago" (Andrew Schulman) Unauthorized Windows 95: Developer's Resource Kit (Andrew Schulman) Windows 95 System Programming Secrets (Matt Pietrek) and periodicals of the era: BYTE Magazine Microsoft Systems Journal which some of which you can find on old MSDN CDs. This blog post has links to the first thirteen such releases, as uploaded to Internet Archive: https://virtuallyfun.com/2019/03/27/early-msdn-cds-on-archive-org/ Chelson, you recent suggestion is along the lines of saying "if you want DOS, just run cmd.exe on Windows 11". -- Kirn Gill II Mobile: +1 813-300-2330<tel:+18133002330> VoIP: +1 813-704-0420<tel:+18137040420> Email: segin2...@gmail.com<mailto:segin2...@gmail.com> LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6 On Sun, Jun 9, 2024 at 5:37 AM Bernd Böckmann via Freedos-devel <freedos-devel@lists.sourceforge.net<mailto:freedos-devel@lists.sourceforge.net>> wrote: > > Something targeting 16-bit Windows would be easier since the official API has > been frozen since 1992 Are you sure it would be easier? 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 :) > > I've been looking at the work needed to do so and most of it seems to lie in > properly recreating the KERNEL and possibly GDI module(s). There is a book, > "Windows Internals: Implementing the Windows Operating Environment" that does > a good job of describing the Windows 3.1 kernel (and some other things), and > can be paired with "Undocumented Windows: A Programmer's Guide to Reserved > Microsoft Windows API Functions" (the Andrew Schulman books) as a companion > text (Windows Internals itself recommends this book in the preface.) > > Drivers can be sourced from DDK examples or just plain use existing driver > binaries. > Do not forget USER.EXE. To my knowledge, much of the windowing and controls stuff is implemented in it. Perhaps as a "proof-of-concept" one could restrict to a real mode only, single program runtime facility. There, things like the dynamic linker and loader for NE executables / DLLs etc. and other basic KERNEL, GDI and USER functions could be implemented and tested. Regarding the NE loader, that could potentially be interesting to other DOS application programmers, giving them the possibility to use DLLs etc. Thanks for the book references! Bernd _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net<mailto:Freedos-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net<mailto:Freedos-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net<mailto: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
