[Freedos-devel] Announcing readexe 0.1.3
After yesterday's inquiry about readexe's roadmap, I took a brief look at my local work repos on both my Windows and my Linux build systems, committed my unsaved changes, did a little Valgrind, and shaped up version 0.1.3 this morning. This is mostly a bugfix release to address memory leaks found when running on Linux with Valgrind. NEW FEATURE: * Displays VMM version when reading WIN386.EXE from Windows 3.x (or DPMI.EXE from NEC OEM MS-DOS 5.00a for PC-98 - the DPMI.EXE there is a standalone version of the Windows 3.0 Virtual Machine Manager! MS-DOS itself ships a few VxDs, even!) BUGS FIXED: * Memory allocated during program startup isn't freed when displaying usage text and exiting. I've also provided a number of prebuilt binaries for Windows, DOS, and OS/2. Check it out: https://github.com/segin/readexe/releases/tag/v0.1.3 -- 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
Re: [Freedos-devel] 16-bit Windows development
> 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] "BLOCKDEV" 0x00076800 0x028e (654 bytes) [16] "PAGEFILE" 0x00079400 0x048b (1163 bytes) [17] "VFD " 0x0007c400 0x018a (394 bytes) [18] "PARITY " 0x0007dc00 0x0168 (360 bytes) [19] "BIOSXLAT" 0x0007f400 0x01b4 (436 bytes) [1a] "VCD " 0x00080c00 0x0507 (1287 bytes) [1b] "VMCPD " 0x00084400 0x021e (542 bytes) [1c] "COMBUFF " 0x00086c00 0x0211 (529 bytes) [1d] "CDPSCSI " 0x00088400 0x0155 (341 bytes) [1e] "QEMMFIX " 0x0008ac00 0x01ac (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
Re: [Freedos-devel] 16-bit Windows development
ReactOS is a moving target because it tracks current Windows (for better or for worse.) Something targeting 16-bit Windows would be easier since the official API has been frozen since 1992 (with a few additions for thunking added in Windows 95 - but that's really only for interacting with 32-bit libraries and programs.) The target is fixed in stone, as it were. There's no need to worry about porting to 64-bit or implementing the behaviors of Windows 11 or what-have-you. It's unchanged I'm 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. As for the references to NT 3.51, I'm pretty sure you're referencing MVDM/WOW16/KERNEL31, which is the WOWified Windows 3.1 kernel source. I'm aware of it and it doesn't take a lawyer to tell you that this is "don't even look, much less touch." Of course, a competent copyright lawyer would dispense the same advice. Any project that involves THAT code in ANY way is committing legal suicide and inviting Microsoft to destroy them in court (barring MS relicensing said source.) If I'm to get anywhere in such an endeavor, I need to avoid such things entirely. On Sat, Jun 8, 2024, 16:50 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
[Freedos-devel] 16-bit Windows development
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
Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?
> is Ansi-C the right year compiler and language?
"Ansi-C"? ANSI is the American National Standards Institute. "ANSI C"
refers to the standard version of the C programming language ratified by
ANSI for use in the United States of America. In colloquial usage, "ANSI C"
refers to the 1989 version of the ANSI C standard, ANSI X3.159-1989, which
is also referred to colloquially as "C89" or "C90" (as ISO adopted the same
standard as ISO 9899 in 1990.)
The OpenWatcom C compiler is mostly compliant* with C99. It generally
supports C89 ("ANSI C").
*I am not sure of the extent of the incompatibility, but I have not
encountered issues with versions 1.9 or the 2.0 fork. It may fully
implement C99 at this point.
--
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
On Wed, May 22, 2024 at 8:27 PM Richard Stoltenberg via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:
> Greetings:
> I got my program to compile under watcom 1.9 but it has errors. Not
> looking for help directly, but good programming documentation. Does anyone
> have any good free/paid programming books with examples? found: The ANSI C
> Programming Language
> by Brian W. Kernighan, Dennis M. Ritchie (not cheap)
> and Ansi C Programming Concept Kindle Edition
> by Sivarasan R (Author) cheaper
>
> is Ansi-C the right year compiler and language? wasn't clear from a
> view of your youtube videos and website, I enjoy. Thanks.
>
> ___
> 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] Where is the source code?
> We can ensure reaching it by lifting the entry barriers so high that none of the young people bother dealing with FreeDOS any more. If the written word is a barrier so high that the young people skip dealing with FreeDOS, then how do you expect them to USE the OS to begin with, much less WRITE code for it? (This thread is strictly and solely about developers, not end users, in case you've forgotten.) In such a world, FreeDOS has already died because it's a textual command line, not a GUI full of emojis (say, maybe like the intake nurse's keyboard of 2505 in the movie Idiocracy) Did you forget we're talking about DOS here? -- 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 On Fri, May 10, 2024 at 4:03 AM Bernd Böckmann via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > > > The moment FreeDOS starts pushing video lessons for developer tutorials > is essentially the day that FreeDOS has died. > > Well, that is a little bit of an exaggeration :) FreeDOS has died if > people stop being interested in it, and with DosBox etc. as alternatives we > are short of being at this point. We can ensure reaching it by lifting the > entry barriers so high that none of the young people bother dealing with > FreeDOS any more. > > You have valid points in pointing out that video lessons are perhaps not > the best learning format for coding, but they definitely catch more > interest than a five page article. No one requests throwing away the > available documentation and replace them by videos. But they are a valid > way of introducing people to topics they are generally interested in. If > they want more information, they will search for them and probably find > them in form of articles or books. > > You have problems calling it „developer videos“, fine, lets find some > other name for it… > > Greetings, Bernd > > > > ___ > 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] Where is the source code?
Listen, for developer documentation, we should be skipping YouTube entirely. There's absolutely no good developer documentation that's shipped in video form. In fact, the medium prevents it. You cannot copy and paste from a video. You cannot ^F and search through a video. You have to deal with prerendered text that may be in a terrible font or be illegibly butchered by video compression (especially depending on the color schemes used!) You have to deal with either no subtitles, or machine-generated subtitles both full of transcription errors and devoid of grammar for the vast majority of videos. It's very rare that the video uploader will go behind himself and craft proper subtitles (with proper grammar!) for you to read (or ^F search through, in the few video-playing environments that allow that - YouTube is NOT one of them.) You have to deal with various random spoken accents which can yield the content unintelligible for some (or even most) viewers. And absolutely most important: You are emphasizing spoken language over written language, which is antithetical to computer programming - a written exercise. Computer code is nearly exclusively text, you need to think in text, and you thus should want the educational materials to be majority text, if not exclusively so. Video content should be limited to small demonstrative clips that are embedded into an otherwise written document, similar to how Twitter posts get embedded into news articles. If you struggle with reading, you're plainly not going to cut it as a software developer, no exceptions - every single line of code you will ever interact with will have to be read, it will not be spoken aloud for you. Every line of code you ever write will be, well, written; you will not speak it aloud. The moment FreeDOS starts pushing video lessons for developer tutorials is essentially the day that FreeDOS has died. -- 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 On Wed, May 8, 2024 at 10:29 AM Bernd Böckmann via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > > > I like that idea. I think a good place to add these would be in the > > "Technical information" section on that page, maybe as another row of > > "info boxes" before (or after? not sure) the row that has RBIL, VGA > > programming, and the Graphics Programming book. > > I would put it below Technical Information as another row. > > > > > What are some good YouTube channels about DOS programming that I > > should point to? > > I like the following playlist. He uses Turbo C, PowerBasic, NASM. While he > does it on DosBox, the skills are transferable. Be aware: heavy german > accent :) > > https://www.youtube.com/playlist?list=PLGJnX2KGgaw2L7Uv5NThlL48G9y4rJx1X > > > > ___ > 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] I16GCC would need DJGPP, but DJGPP not present in FDT2404
> Doing "set DJDIR=c:\devel\djgpp" I get stdio.h not found when compiling hello world. Cargo cult programming is your crime. You copied and pasted the example as if it's some magic incantation. It's not. You're supposed to replace the path given so that %DJDIR% points to the base of your gcc-ia16 installation. I can't tell you where it's installed on your system - you are supposed to be keeping up with that yourself. Remember: This is DOS, not Windows, Linux, etc.; the work is up to YOU! -- 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 On Tue, Apr 9, 2024 at 12:02 PM Paul Dufresne via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > I tried to install I16GCC from bonus CD of FDT2404. > When I tried to compile a program it says I need to set DJGPP environment > variable. > https://gitlab.com/tkchia/build-ia16/-/releases says: > > "If you get the error message i16gcc.exe: fatal error: environment > variable DJGPP not defined when running i16gcc.exe, you can do one of the > following: > > Install the DJGPP base environment first, and then set the DJGPP DOS > variable to point to its djgpp.env, e.g. set > DJGPP=c:\devel\djgpp\djgpp.env. (See DJGPP's readme.1st for more > information.) > Alternatively, if you do not wish to install DJGPP, just set a DJDIR > environment variable thus: set DJDIR=c:\devel\djgpp." > > Doing "set DJDIR=c:\devel\djgpp" I get stdio.h not found when compiling > hello world. > > And it seems DJGPP is not on FDT2404-BNS.ZIP. > > On 1.3, DJGPP programs are listed: > > http://ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/report.html > > But not at all in: > > http://ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html > > What I need to have i16gcc working in FDT2404? > > Is DJGPP supposed to be in FDT24040? > > > > > > > > ___ > 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] FreeDOS Interim Build T2310 - no free space on CD
I think you're blinded by DJGPP. At no point did I argue for keeping THAT mess in... or gcc-ia16. You just assumed that I would, so assumed that's exactly what I was advocating for. No, keep it simple. A "base" disc's dev tools shouldn't take more than 20MB at most. An assembler, a basic 16-bit C compiler (Small C?), a 'make' tool of some sort, a cheap linker (if the compiler and assembler don't already include these.) Maybe FreeBASIC. The largest piece of this would be FreeBASIC at 8MB for version 1.10 released this year. It's been a while since I've looked, but certainly one could ship basic dev tools on the base disc and leave the heavyweight GNU crap for the supplemental disc. -- 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 On Wed, Oct 4, 2023 at 7:53 PM Ralf Quint via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > On 10/3/2023 11:30 AM, Michael Brutman via Freedos-devel wrote: > > There is no point in punishing everybody by shipping tools that most > > people don't use. You can probably count all of the active DOS > > developers on your fingers and toes. > > > > All of the various tools and compilers remain available for download. > > Not being on the CD image is not the barrier it used to be. > > But could you consider that there are so few people programming in and > for DOS simply because there are no simple to use programming > environments available and instead some folks keep pushing oversized > Linux influenced behemoths of programming environment which need to be > shoehorned to run and produce results within the basic limitations of DOS? > > > 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
