Re: [Freedos-user] Assembly Language and BASIC
Hello Liam Proven,
[re Pascal, Modula, etc.]
You [Rugxulo] also said: >> (So it was too many competing languages,
honestly.)> Also not really
fair.> I mean, arguably, yes, but there are also dozens of variants of
C.> There's original C, K&R C, Plan 9 C, ANSI C, C 99, C11, C17 and soon
C23.> All are C. All are different. Code from one may not work in others.
And of course there is Limbo, Go, C++, C#, D, and myriad variants.
Not quite. There is a clear difference between a "dialect" of C, and a
language that is only kind of "influenced" by C. In brief, any compiler
that claims to be a "C compiler" --- including GCC, the Intel C
compiler, or even Plan 9's C compiler --- had better be able to compile
#include
int main()
{
printf("Hello world!");
return 0;
}
into a program that actually prints "Hello world!".
In contrast, we do not expect (say) a Java, Go, or C# compiler to accept
the above program, or even to make it print "Hello world!". Because
Java is not a dialect of C, and does not claim to be one.
Thank you!
--
https://gitlab.com/tkchia
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Assembly Language and BASIC
Hello Daniel, I am unfamiliar woththe C languages, but does it also allow one to mix both assembly in with the C source code? Are there any other languages In short, yes, most C compilers allow you to write "in-line" assembly inside a C language source file. However, note that this is not a standardized language feature: different C compilers have different grammars (and semantics) for writing in-line assembly code, so you need to consult the documentation of the specific C compiler(s) you want to use. The GNU C compiler (GCC) in particular has a very powerful inline __asm (...) feature that is designed to play well with the compilers' optimizer. Again, read the documentation. :-) Some C compilers (e.g. the Amsterdam Compiler Kit) do not allow writing assembly code "in-line" as part of a C source file. But even with these, then you can probably still write your assembly language code as a separate module and link it with your C code. Thank you! -- https://gitlab.com/tkchia :: https://codeberg.org/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] how to get dosemu working under ubuntu installed in wsl
Hello Travis, Ok, odd question, (lots of emulation), but I've got ubuntu 20.04 running under win10, using wsl. I can't seem to get dosemu installed under that version of ubuntu (though it works fine under a real ubuntu system I have). When I try to install dosemu under the ubuntu 20.04 running under wsl, it tells me the package isn't there to be installed. I currently use dosemu2 (https://github.com/dosemu2/dosemu2), which can probably be described as a kind of bleeding-edge continuation of the dosemu project. I believe Ubuntu no longer distributes the original (?) dosemu 1.x. There is an "official" Ubuntu Personal Package Archive (PPA) for dosemu2 at https://launchpad.net/~dosemu2/+archive/ubuntu/ppa. Be forewarned though that this is updated very frequently and might thus be unstable. Me, I also have a PPA at https://launchpad.net/~tkchia/+archive/ubuntu/de-rebus which hosts a copy of dosemu2. This is less frequently updated, and hopefully more stable. :) Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Interesting comment by Walter Bright
Hello Louis, hello Mercury 13, >> He claims "The DMC++ compiler is far and away the best C++ compiler on DOS." >> https://news.ycombinator.com/item?id=30127615 Interesting he doesn't mention that Digital Mars is his own company. "Digital Mars C/C++ is Boost licensed." and "DMC still gets updates and code gen improvements." Well, I _still_ want to know how to build DMC++ from source --- and for MS-DOS targets. The Digital Mars source code they put up on GitHub seems to have only vestiges of support code for OMF, far pointers, etc.? Is the MS-DOS target port still actively maintained? Is this port specifically under a Free Software license? -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BM cannot boot FD 1.2
Hello Ray, What about the KERNEL location in the tree? Prior to 1.2 it was in the root, now it is in FDOS\BIN. If I run SYS C: from a 1.1 Floppy, then copy 1.2 KRNEL386, as KERNEL, over the 1.1 KERNEL, should that leave me with the 1.2 kernel where it belongs on the drive? Huh? I would expect there to be a kernel.sys or fdkernel.sys in the root directory of the new FreeDOS 1.2 partition. Thank you! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Video complains that DOS should not be maintained
Hello Travis, linux box setup and transferred the domain to that. The nice thing about using dos for your networking, (which someone else said way more eloquently than I could, paraphrasing here), is that since dos doesn't have a native tcp/ip stack, if the app dies, so does the tcp/ip connection, so you don't have to worry about folks exploiting your system to get in via backdoors. or buffer overruns. Actually I think it is a bit of a misconception to say that (MS-)DOS is secure because it lacks kernel-space device drivers. The reality with MS-DOS and compatibles, is that there is not much of a security boundary between the system kernel and user processes. This is exactly why one can write a network device driver as a user application --- because a user process often has unlimited access to the PC hardware anyway, just like the system kernel (!). Anyway, other than that DOS programs tend to be simpler and smaller, I do not really see much that makes DOS intrinsically "more secure" than more modern systems. There has been a lot of work done in the last few decades or so towards hardening modern OSes --- e.g. there is work to harden the Linux kernel, from kernel versions 2.x all the way to the current 5.x (https://www.openwall.com/linux/). At least some of this work will need to be adapted to programs running on DOS, if they need to be truly secure. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : DBCS question about dosbox-x
Hello Eric, hello Paul, Hi! I read on https://dosbox-x.com/release-0.83.15.html that DOSBOX-X now supports DBCS for CJK (Chinese, Japanese and Korean) languages. Do you happen to know how they do that? Well, more info about mentioned DOS/V is at: https://en.wikipedia.org/wiki/DOS/V I realize this thread is a bit old, but anyway I recently found that archive.org hosts a copy of Japanese MS-DOS 5.0/V: https://archive.org/details/microsoft-dos-v-5.0-v-japanese The disk images have weird file sizes for some reason, but you can try padding each them to 1.44MiB (1,474,560 bytes). Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How to build FreeCom on open watcom
Good day saito yutaka, I modified config.mak as follow. Other settings are same as config.std[1]. --- ## Memory model of FreeCOM !if $(DEBUG)0 == 10 SHELL_MMODEL=l DEBUG=-DDEBUG !else SHELL_MMODEL=l DEBUG=-UDEBUG -DNDEBUG !endif SHELL_MMODEL_COMP=$(SHELL_MMODEL) Unfortunately, in general, you cannot simply change a MS-DOS program's memory model from "medium" to "large" willy-nilly --- especially when the program contains assembly language (.asm) modules. That simply does not work. The compiled output binary will not behave correctly. Microsoft's blog has a bit of an explanation on what the various 16-bit memory models (tiny, small, medium, compact, large, huge) mean: https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012 Hope the above helps. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DBCS question about dosbox-x
Hello Eric Auer, Hi! I read on https://dosbox-x.com/release-0.83.15.html that DOSBOX-X now supports DBCS for CJK (Chinese, Japanese and Korean) languages. Do you happen to know how they do that? Would it be feasible to port their changes into the I looked a bit at the Git commits for dosbox-x (https://github.com/joncampbell123/dosbox-x/). It seems many of the recent changes have to do with special handling of double-byte characters in short file names when DBCS is active. E.g. if an 0xa4 byte (= `n tilde' in CP437) starts a double-byte sequence, then it is not considered a small letter to be "capitalized" (to 0xa5); and if a 0x5c byte (CP437 backslash) appears as the second byte of a double-byte sequence, then it is not considered a path separator; etc. There are probably also other relevant changes in the source code. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Crynwr package contains PCNTPK.COM
Hello Louis, I don't get what the issue with PCNTPK.COM packet driver is? Per the amdpd.zip file at http://crynwr.com/drivers/00index.html , it is copyright Russell Nelson 1990 w/a GPLv1 license in 1990 and copyright AMD 1993 w/a pseudo Public Domain-ish license (PCNTPK.ASM). While not packaged the way we expect of GPL v2 or v3 code, I think the 1990 copyright and GPL v1 license would supersede AMD's, but IANAL. Russell Nelson wrote many of the drivers and/or skeletons in his collection. "PCNTPK claims 'confidential proprietary information of AMD' but also has GNU GPL v1 and public domain code - really not sure about the license here. This is confusing. The dates suggest it was originally GNU GPL or public domain, then AMD stamped their own 'confidential proprietary information of AMD' license on top of it." (http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages) Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] CMDLINE
Hello Eric, Which command.com version and which version of hexdump are you using? As far as I remember, neither MS DOS nor FreeDOS command.com use the CMDLINE mechanism, maybe you mean the shell (terminal) window of Microsoft Windows? Git logs suggest that FreeDOS's FreeCOM has included %CMDLINE% support since late June 2006. And the error messages that Paul Edwards was getting do seem to come from FreeCOM. So this looks like either a FreeCOM bug or a configuration glitch. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review
Hello Eric, For comparison, at the moment, DOG (shell, 1 file per command), Arachne (browser), Emacs, FreeBASIC, GhostScript, OpenXP, Lynx browser, Pacific C, Pegasus Mail, SETEDIT and various games are better off in their own directories, while several 100 single executable files can nicely stay together in the BIN directory because you would not want PATH to become too long in DOS. The (newer) FreeDOS package format already has a links/ mechanism (http://wiki.freedos.org/wiki/index.php/Package), which allows one to create executable "shortcuts" in a links/ directory to programs elsewhere. I am already using this mechanism in my gcc-ia16 packages. E.g. i16gcc.zip has a file links/i16gcc.bat, which (newer versions of) the fdnpkg installer will transform into a small .com file that hands over to devel/i16gnu/bin/i16gcc.exe. I think this is a simple and straightforward way to keep %PATH% short, and still allow each package's files to (largely) go into its own directory. Perhaps we just need to get more packages and package maintainers to use it. :-) Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review
Hello Johnpaul Humphrey, All the things he finds objectionable I would have called FEATURES. He would do better on Ubuntu. Me, I am not so sure. That was from Laaca --- a developer of DOS programs himself. He also mentions that he had been "using DOS for 27 years". So if he says that things are bad, maybe they _are_ bad (for whatever reason), and we should take heed... Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review
Hello Eric, Finally, the reporter (the whole post has a quite harsh tone) complains that the default install will install FAR too few useful apps and that the package management groups are badly sorted (e.g. no subcategories for utilities) and that there should be no base64 tool in "base"... Apparently the review was from Laaca --- the author of Blocek. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] hardware recommendations
Hello Felix, What this reads is if it has UEFI, it has no basic input/output system. That makes no sense. Without *a* basic input/output system, by whatever Well, in practice, when we talk about "BIOS" compatibility, we are really referring to compatibility with "the" BIOS --- as in, the original IBM PC's ROM BIOS, and the programming interface that it presents. FreeDOS, and many other MS-DOS-compatible operating systems, absolutely need to run on something that is compatible with "the" BIOS. (At least for now.) Such a compatible BIOS not only needs to be able to find a keyboard --- it must also allow (e.g.) FreeDOS and MS-DOS programs to read keystrokes or send commands to the keyboard in a similar way as they might on an original IBM PC. This is the part that will be missing on an UEFI-only system. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why I use DOS a.k.a. FreeDOS for Dummies?
Hello Ralf, Still an excellent tool I consider TROFF, now GROFF, for Unix/Linux -which also exists for Windows, appeared in 1990 (Version 0.3.1) by James Clark) coming from “a text-formatting program called RUNOFF, which was written by Jerome H. Saltzer for MIT's CTSS operating system in the mid-1960s! I wouldn't touch any of that stuff with a barge pole these days. Either LibreOffice Writer already fits the bill, or I would much rather use a tool like Scribus these days... troff (as groff) is still very much alive today, as far as I can tell. And the troff format is still the default source format for man pages on Linux. It is quite a good format for the job, if you ask me. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why I use DOS a.k.a. FreeDOS for Dummies?
Hello Liam, This is indeed interesting --- an OS that is fast and light, and knows at least a few things about modern (21st-century) hardware and software standards. There are a _lot_ of choices out there that are not as bloated as modern Linux tends to be, and not super-simple and limited like DOS (any DOS). In my opinion, the main problem with MS-DOS is not that it is super-simple --- the main problem is that it is old (which is a somewhat different thing). Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why I use DOS a.k.a. FreeDOS for Dummies?
Hello Eric, hello Thomas, PS: Thanks for mentioning https://kolibrios.org/de/download which supports USB (mouse, keyboard, trackpad, storage) in only 1.5 MB. Does it also support your printer and other USB devices? It does This is indeed interesting --- an OS that is fast and light, and knows at least a few things about modern (21st-century) hardware and software standards. I guess I overlooked it somehow earlier, probably because it is neither on GitHub nor on GitLab. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why do you use DOS
Hello Ralf, On a slightly related note: https://www.pcjs.org/blog/2018/05/27/ . :-) Well, that article has a whole lot of nothing about "CALL 5". Read on carefully. :-) There is a VM of PC-DOS 2.0 which includes a utility that was part of Microsoft Word ... and the utility uses `call 5'. (Apparently --- per the blog post --- the utility using `call 5' survived the transition from the 8086 to the 80286, and it was on the 80286 that it started to cause problems (because of A20).) (Technical Reference) manual, nor do I recall this mentioned in more than passing in any 3rd party "DOS internal" kind of books. The `call 5' syscall interface is quite simple: * only syscalls 0--0x24 are allowed; * the syscall number goes into cl, not ah; * all other syscall parameters are as for `int 0x21'. The interface does not really give programmers any extra power that normal `int 0x21' calls cannot give --- which might explain why most "DOS internal" texts do not care much about it. But it is there, and even later versions of MS-DOS (and FreeDOS) still have it. By and large, people just need to stop spreading the myth that "DOS is copied/stolen from CP/M" or similar nonsense. True that. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why do you use DOS
Hello Ralf, The "CALL 5" equivalent was never properly implemented, I guess Peterson ran into problems with the differences of the 8080 and 8086 CPUs. [...] And you will have a hard time to find any serious documentation on that CALL 5 stuff for any version of DOS. And I would be surprised if there would have been anything left after the rewrite of DOS for MS-DOS 2.0. The `call 5' implementation was very clunky --- involving running some pesky extra instructions not needed by the `int 0x21' path --- but it most probably did work back then. In a way, it had to work --- the programs translated using Paterson's Z80-to-8086 source code translation relied on the `call 5' actually working as a syscall mechanism. On a slightly related note: https://www.pcjs.org/blog/2018/05/27/ . :-) Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why do you use DOS
Hello Liam, hello Tom, And according to the mainstream account (?), CP/M-86 would not be released until late 1981. QDOS was released earlier, in mid-1980 (https://archive.org/stream/byte-magazine-1980-08/1980_08_BYTE_05-08_The_Forth_Language#page/n173/mode/2up). QDOS's system call interface (`call 5') was in fact based on that of the _8O8O_ version of CP/M, while CP/M-86 decided instead to implement a different syscall interface (`int 0xe0'). I misspoke a bit here: `call 5' was just one of QDOS's system call interfaces (the other syscall interface supported by QDOS would be the `int 0x21' that MS-DOS programmers are familiar with). Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why do you use DOS
Hello Liam, All right, I have to concede that point. Thank you --- glad we could agree. :-) I still maintain there is a bit of a difference between copying a rival's API in order to launch a competing product, and copying a rival's API in order to do something completely different with it. Personally I am not very sure that the original purveyors of QDOS or MS-DOS 1.x intended for their offerings to "compete" head-on with CP-M/86. Perhaps this question is best left to the academic historians. According to Paterson (the author of QDOS) himself (http://dosmandrivel.blogspot.com/2007/09/design-of-dos.html), "We knew Digital Research was working on a 16-bit OS, CP/M-86. At one point we were expecting it to be available at the end of 1979. Had it made its debut at any time before DOS was working, the DOS project would have been dropped. SCP [Seattle Computer Products] wanted to be a hardware company, not a software company." And according to the mainstream account (?), CP/M-86 would not be released until late 1981. QDOS was released earlier, in mid-1980 (https://archive.org/stream/byte-magazine-1980-08/1980_08_BYTE_05-08_The_Forth_Language#page/n173/mode/2up). QDOS's system call interface (`call 5') was in fact based on that of the _8O8O_ version of CP/M, while CP/M-86 decided instead to implement a different syscall interface (`int 0xe0'). Thank you! -- https://gitlab.com/tkchia :: https://gitlab.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why do you use DOS
Hello Tom, JMP 5 terminates a program Just a minor nitpick: that will be `jmp 0' (with cs = PSP). `call 5' performs a syscall with the syscall number in the cl register. (Also, I recall --- if I remember correctly --- the actual CP/M-86 actually exposes a different `int 0xe0' interface for syscalls; and MS-DOS's `jmp 0' and `call 5' interfaces were actually based on the 8080 version of CP/M.) Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Why do you use DOS
Hello Liam, that's the way other programs talk to the OS; copying it was and is considered fair game. Is it? By whom? The whole discussion around the recent Google v. Oracle court case? If anything, it should show clearly that there is _nothing_ _nefarious_ whatsoever in writing a system which implements a similar API --- or even the exact same API --- as some other system. It only "sounds" nefarious in the MS-DOS 1.x case, because Microsoft "The Great Satan" happens to be involved. CP/M's API was not public info, although in those early days most companies did publish source code to enable software to be ported. I am pretty sure that _any_ interface for interacting with an OS _has_ to be public information at some point. Otherwise there is no way for third parties to actually, well, write applications for it. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] GNU General Public License...
Hello Michael, The license MUST be viral. Folks, anyone who complains about it being viral doesn't understand it at all. Google is a monopoly. Google Sorry, but the arguments you make do not even begin to make any sense at all. You are basically just stringing a lot of baseless conspiracy theories together, and saying that Mr. Stallman is the only way to defeat this Vast Conspiracy(tm), because reasons. And I do not agree with that --- because none of that makes any sense. Good day. -- https://github.com/tkchia :: https://gitlab.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FSF?!
Hello Adam, I've never really understood why people complain about the GPL being viral - perhaps you can enlighten me with another viewpoint. I only ever see it from the point of view where someone is very happy to make use of code another has provided for free, but they don't want to share their own code in return, which seems a bit selfish and unfair to me. I am sure the numerous developers working on Apache, FreeBSD, etc. would disagree with that characterization. Perhaps --- at least this is how I view it --- the problem is not that the GPL requires people to "share in return", but it requires people to "share in return" in extremely specific, prescribed ways, which also happen to be incompatible with other extremely specific, prescribed ways to "share in return". And we end up with a situation where even the FSF's own libgcc, autoconf, and bison projects --- there may be others --- decided they need to open up "special exceptions" to the GPLv3 terms. E.g. "As a special exception to the GNU General Public License, if you distribute this file [./missing] as part of a program that contains a configuration script generated by Autoconf, you may include it under the same distribution terms that you use for the rest of that program." and "As a special exception, when this file is copied by Bison into a Bison output file, you may use that output file without restriction. This special exception was added by the Free Software Foundation in version 1.24 of Bison." Something is not well, if we must have so many "exceptions" for Free Software to work as it should. (My libi86 project happens to use autoconf, so yes, this issue is indeed quite relevant for my code.) Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FSF
Hello Rugxulo, but that doesn't mean he should be heavily punished. Just because someone doesn't agree with him, even if he speaks egregious words, doesn't mean he should be destroyed. I reject that kind of irrational anger (especially You cannot have it both ways. Either opinions are harmless --- then Mr. Stallman has no reason to fear what others say about him --- or we acknowledge that expressed opinions sometimes can, and do, have power. I would also disagree with the suggestion that this is just some "drama" in some faraway place that will never affect us, so we can just "ignore" it. In practical terms, I am especially worried that I might have to pore over the Codes of Conduct of conferences to look for hidden gotchas. Because there is the claim that "speakers or audience members may be subject to verbal or even other types of harassment" (https://wwahammy.com/on-safety-at-libreplanet/) just by attending one of FSF's conferences. The "drama" does not affect us, until it does. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FSF
Hello Rugxulo, Honestly, he's been known as "very eccentric" for many years. I don't think anybody is surprised. He has opinions and voices them (whether unpopular or not). You know what they say about opinions, right? Everyone has one. Well, I happen to lurk around on the GCC mailing list. The impression I am getting is that the issue might be much larger than just "someone having unpopular opinions": e.g. https://gcc.gnu.org/pipermail/gcc/2021-March/235161.html . Myself, I am not sure what to think of it all. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Latex / long filenames
Hello Tomas, The "dir" command only shows 8+3, and when I manually rename using "move", the name gets truncated (rather than getting the tilde plus number). Perhaps try doing the renaming using the Bash shell that should come with DJGPP? DJGPP Bash should support long file names. I think FreeDOS command.com is not LFN-aware (yet). Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] COWGOL programming language
Hello Bruce, hello Dennis, No recursion and no floating point will be blockers users need to keep in mind, but being able to build for 8bit micros like the 8080, Z-80, and 6502 is a definite plus.. The Cowgol page (http://cowlark.com/cowgol/index.html) says that the lack of recursion is because most of the target platforms "don't really support stack frames". I wonder if that means there will also be a problem writing, say, thread-safe routines or re-entrant routines. Incidentally, the Cowgol author, Mr. David Given, also currently maintains the Amsterdam Compiler Kit (https://github.com/davidgiven/ack), which was reportedly used in Minix. I think ACK might also be potentially useful for MS-DOS program development. Thank you! -- https://gitlab.com/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Invalid opcode - where do I even begin?
Hello Michal, hello Louis, I've run some software on Pentium 3 Tualatin S on FreeDOS and it's getting an invalid opcode error. The error precisely says "Invalid opcode at ..." where ... is a bunch of 16 bit variables. Saying "at" is really misleading and doesn't make any sense, since such a high address like let's say 628a 3002 206f 2b43 202b 202d 6f43 7970 6972 6867 I think those are binary instructions. Not actual addresses. You could try disassembling here [0] but a quick cut & paste gave an instruction sequence that is non-obvious to me. If Contra is a debugger/mod, then The list of 16-bit values is a stack trace. The first three shortwords should give the ip and cs of the offending instruction, and the flags register value --- these will be at the stack top when the "invalid opcode" exception happens --- and the rest of the shortwords are the contents of the stack further down. If I deliberately try to run an invalid instruction under a DEBUG.COM session, this happens: == A:\>debug -a 2902:0100 db ff,ff 2902:0102 -t Invalid Opcode at 0100 2902 7306 20CD 9894 9A00 FEF0 F01D 1D9F 236A 07C6 109A == In your case, this probably means that the CPU tried to run an invalid instruction at cs:ip = 0x0:0x628a (!?), with flags = 0x3002. If I understand correctly, Quake is a 32-bit protected mode program. But the "Invalid Opcode" message comes from the FreeDOS kernel, which runs in real (or maybe V86) mode. So perhaps something in real mode was directly causing the error. Or (less likely?), something bad happened while Quake was running in protected mode, and the exception was "reflected" to real/V86 mode. In either case, I would expect the true root cause of the error to be a bit further back in time. Thank you! -- https://github.com/tkchia :: https://gitlab.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Which C compiler for targeting DOS?
Hello Adam, * I would like to be able to produce a native DOS real-mode .exe file that will run in an emulator like DOSBox and on a real 8086 PC running DOS (i.e. without protected mode or extended memory). It looks like there is an "ia16" port of GCC but this seems to produce ELF files rather than .exe? gcc-ia16 (which I had been working on) does indeed produce 16-bit .exe (and .com) programs which can run on MS-DOS. It uses ELF mainly as an intermediate object file format. In terms of support for DOS programming idioms --- e.g. huge pointers --- I would say Open Watcom is superior to gcc-ia16. But you might still find gcc-ia16 useful, depending on your needs. Both gcc-ia16 and OW allow for "native" compilation (the toolchains run on MS-DOS + 32-bit DPMI, and will produce 16-bit DOS programs), and for cross-compiling from Linux to MS-DOS. You can find pre-compiled binary packages for gcc-ia16 and OW, for both these use cases. Thank you! -- https://github.com/tkchia :: https://gitlab.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Casio Algebra 2.0 can Freedos be installed?
Hello Bob, hello Eric, >> This is supposed to have a V30 processor and Rom-Dos. Haven't had time >> to check it out thoroughly yet. >> I should have asked if it can be installed by a clutz. >> Specs on Wikipedia https://en.wikipedia.org/wiki/Casio_Algebra_FX_Series Hi! Interesting question. This calculator has only 146 kB RAM and only 256 kB of the ROM is reprogrammable flash. Also, the display has very low resolution. You might be able to get some workable solution by starting from Rayer's ROM OS approach, but everything is very small in that calculator. So you probably have to be really experienced to get it to work. And you have very little space to add interesting files to work with, too. http://www.rayer.g6.cz/romos/romose.htm My guess is that the calculator does not have IBM-PC-compatible hardware or even an IBM-PC-compatible BIOS (even RayeR's ROMOS assumes there is such a thing). This will likely be one of the main problems in getting something like FreeDOS to work on the device. Certainly the calculator's CPU may be compatible with that used on machines that run DOS. But the rest of the hardware --- including the key input, screen output, and even serial communications (?) --- seems very different indeed. Meantime, without knowing more about its internal workings, it is hard for me to say more. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Make sure your opinion is heard
Hello Jerome, Some random additional thoughts, I guess some times there was a little confusion with the 1.2 release over a FULL install. Maybe a good way would be to call a "FULL minus EXTRA" install by a less confusing name? E.g. perhaps call it a "RICH" install or something along those lines. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS/16M (was: FreeDOS 1.2 installed on iMac (2011) - success but there are issues)
Hello Ralf Quint, I am not sure if you guys all missed a previous post where I said I found a reference that there are issues with some SMM BIOS implementations, providing legacy USB support (for keyboard and mice) and software that is trying to switch in "long mode" (which also might be used by some memory managers). Which could simply mean that this no-so-PC BIOS in that Mac just isn't up to snuff for these kind of things... Well, we do have some detailed information about this particular error. Namely, there is a message saying "DOS/16M: [26] 8042 timeout", and using a different DOS extender or pre-loading a DPMI host seems to work around it. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS/16M (was: FreeDOS 1.2 installed on iMac (2011) - success but there are issues)
Hello Hollowone PL, hello Eric Auer, DOS/16M error: [26] 8042 timeout DOS/16M error: [26] 8042 timeout ... The 8042 is the keyboard controller. You are using the rEFInd boot manager on iMac, without Bootcamp. I assume that means you had to load some CSM, either provided by Apple or by rEFInd, to have BIOS services for FreeDOS? Apparently it does not simulate a keyboard controller, while DOS/16M, the DOS extender of your app, is trying to access the keyboard without relying on BIOS services for that? It might be that DOS/4GW was trying to use the keyboard controller ports to read or toggle the A20 enable status (https://www.win.tue.nl/~aeb/linux/kbd/A20.html), or some such. Open Watcom's wmake.exe does use DOS/4GW. (And, in its internal messages, DOS/4GW sometimes confusingly refers to itself as "DOS/16M"...) In any case, I suppose yes, perhaps loading another DOS extender (such as DOS/32A), or pre-loading CWSDPMI, would work around the problem. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS/16M (was: FreeDOS 1.2 installed on iMac (2011) - success but there are issues)
Hello Hollowone PL, With this I have few starter question as a user: - DOS16/m is a 16bit protected mode extender. Does it mean that FreeDOS runs in 16bit protected mode from the command line or perhaps some driver is interfering or rather the iMac I use has hardware that may cause some obvious incompatibilities. Can you give us more details about the issue(s) you encountered? For example, which particular tools were you trying to use? What were the error messages? Was FreeDOS running in "really" Real Mode, or in Virtual 8086 mode? (Meanwhile, my wild guess is that the errors were because the iMac is not quite compatible with the IBM PC at the lower levels --- especially the layout of physical memory and I/O ports. But maybe I am wrong.) And, I would very much like to know more about how you got FreeDOS working on a UEFI machine. I have lately been trying to find information on this. :-) Hello Random Liegh, hello Jose Senna, I'm not sure what DOS16/m is -it sounds like a DPMI server? If so, then it provides 32-bit addressing >to dos programs. AFA I remember, DOS/16M is a DOS extender to allow use of DOS in protected mode. It predates DPMI specification and is geared towards the 16-bit protected mode available in the '286. I recall there was the DOS/16M DOS extender --- for the 286's 16-bit protected mode --- and also DOS/4G --- for the 386's 32-bit protected mode --- by Rational Software. (16M would refer to the 24-bit physical address space supported by the 286.) For some reason, Open Watcom still has some vestigial support for producing DOS/16M executables, and the OW source code provides some information on the format of these things. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Old BIOS issue
Hello ZB, hello Eric, I found some basic information here: https://www.daqarta.com/y2kure.htm (I mean "BACKGROUND" paragraph), but when possible I'd like simply to modify BIOS and resolve the problem "once for always" It basically says there are many ways in which hardware or software could fail to handle the year, but you do not say WHICH of them affect YOU. In particular, you could give it a try and change that "19" to "20" in your CMOS memory :-) Maybe your BIOS just fails to store the changed values. I guess it cannot hurt to ask a few questions: 1) What does the PC say that the "current date" is, at startup? 2) What version of DOS is it running? I am wondering if the problem is that the old PC does not have a working real-time clock at all, which would mean it cannot keep track of the time once the power goes off. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Floppy fetish search
Hello Eric, In addition, I have found a small number of floppy disks in CP/M format, which are very likely readable using some of the drives here, but I do not know HOW to read them, software wise. I cannot even use dd to make a diskimage, probably different sector sizes? In case it helps: I came across a blog post about extracting files from CP/M disks with weird sector sizes: https://www.classic-computers.org.nz/blog/2017-04-15-adventures-with-an-8-inch-disk-drive-part3.htm Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dosemu on its own - does it exist?
Hello ZB, Actually I was hoping it could be "thinner layer"... but, as I wrote, only know I'm trying to find out, how exactly "virtual x86 mode" works Basically --- as Eric Auer sort of explained --- a "virtual 8086" is a special kind of unprivileged protected-mode task, that runs under a 32-bit protected-mode OS (or, if there is no actual OS, a monitor program). The memory mappings of the "virtual 8086" --- that is, how the "virtual" 1 MiB address space actually maps to physical memory --- and the device I/O, are governed by the 32-bit OS. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Open source thoughts about my DOS stuff
Hello Eric, My impression of git compared to svn is that the use of random hex numbers instead of sequential version numbers makes it very hard for me to get an overview what happened when in projects seen on the website, am I missing something? [...] > Having no SVN, CVS, GIT, HG for DOS tells me > that we are stuck to cross-compilers or people > who just download in other OS, then use in DOS? I currently use GitHub together with Travis CI for building and doing automated testing for my libi86 project --- see https://github.com/tkchia/libi86/ and https://github.com/tkchia/libi86/releases/ . I understand there is a way to get Travis CI to automatically upload build artefacts back onto a GitHub repository's releases page, but I have not tried this yet. For doing automated builds on a compile farm, I think you _will_ need to prepare some sort of cross-compiler or DOS emulator at some point --- I do not know of any modern compile farm that directly supports toolchains running on MS-DOS. But perhaps I am wrong. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] LFN Support in DOS4GW Environment
Hello Anand,
I wrote a small program in C to create a file with a long file name as
follows.
void main(void)
{
FILE *fptr = fopen("e:\\aerosystems.txt", "w");
fprintf(fptr, "Genesys\n");
fclose(fptr);
} // END main()
And then I compiled using the Watcom compiler:
It seems the Watcom libraries do not use long file name support by
default. Perhaps you can try to see if LFNs work if you define a macro
__WATCOM_LFN__ before including system header files?
#define __WATCOM_LFN__
#include
...
Thank you!
--
https://github.com/tkchia
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Microsoft Open-Sources GW-BASIC
Hello Dennis, As for the AWK portion, I have tested my script for munging the GW-BASIC source files with both GNU awk (gawk) and mawk. Were any changes required to your original script to get it to work as expected in gawk *and* mawk? To my surprise, no, not at all. :-) Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Microsoft Open-Sources GW-BASIC
Hello Rugxulo, hello Dennis, >> What exactly does "semi-working" mean? It seems like graphics commands >> aren't supported? That's no biggie (IMHO) as long as it can do simple >> file I/O. Well, direct commands seem to be working quite OK. But yes, large chunks of functionality --- graphics, (PC speaker) audio, serial/parallel ports, etc. --- are simply not there yet. And, I have not quite fully tested the parts that are there. There is still a long way to go, and I can probably use some help here. Thank you. I never understand when people prefer ancient MASM over modern JWasm. Well, this GW-BASIC version (1983) was written before JWasm even existed. (I guess we cannot fault the Microsoft developers then for not catering to a build tool that simply wasn't.) On a side note, you're using GNU Make and AWK (to cross-build?). I do wonder if DJGPP Make (or even other AWK implementations) would work for us here. DJGPP make is mainly just a port of GNU make, is it not? As for the AWK portion, I have tested my script for munging the GW-BASIC source files with both GNU awk (gawk) and mawk. Awk is still useful on *nix - various things like build recipes may use it in scripts - but for most purposes, perl has replaced it. (I consider that a pity. Awk is smaller and faster, and perl may be overkill for a lot of what you might need to do. Former Busybox Agreed. In fact I wrote an earlier version of my source-file-munging script in Perl, but later rewrote it in AWK. :-) Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Microsoft Open-Sources GW-BASIC
Hello Jim Hall, Looks like this person is trying to get the source to build. You can follow or contribute here: https://github.com/dspinellis/GW-BASIC On Sat, May 23, 2020, 2:29 PM Random Liegh via Freedos-user < freedos-user@lists.sourceforge.net> wrote: I tried it with some old, old versions of MASM and got exactly nowhere. But then again, I have no idea what I'm doing. Please let us know how it goes! Thank you for the information. Building on Spinellis's work, I managed to get the source files to build under JWasm and JWlink, after some source code munging (https://github.com/tkchia/GW-BASIC). Many of the needed OEM-specific routines are (still) simply missing from the sources though, and must be filled in somehow. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Microsoft Open-Sources GW-BASIC
Hello Ralf, But still, nobody should get their knickers in a twist just yet, as it is an older version of GW-BASIC from 1983, while the latest version (3.23) is from 1988. And the license kind of disallows to re-use the code from the files, similar to that of the DOS 1.x/2.0 source they published last year... Did I miss something? The LICENSE file in the GitHub repository (https://github.com/microsoft/GW-BASIC) says that it is released under the MIT License. The *.H files and *U files (GIO86U etc.) contain macros needed by the *.ASM files, but I have not checked how complete they are. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] qt and DOs?
Hello Karen Lewellen, >> But meanwhile, forget Calibre under DOS. If you really want to use >> it, run Linux. > the question is, if a compile of Calibre is possible for dos...you know > the focus of this list? smiles. > The qt idea came from a member of the calibre forum at mobileread. Well, it seems to me too that it will take quite a good while to happen, if it happens at all. I see the Calibre source code requires a number of dependency projects to build and run --- not just Qt, but also Python, and SQLite, and perhaps others. So one will either need to get all these dependencies working under MS-DOS --- and these are rather huge dependencies, not small pieces of code --- or, at least, to find suitable replacements for some of them. It seems that there is a port of Python 2.4.2 to MS-DOS on 32-bit systems (http://www.caddit.net/pythond/), so that _might_ be a place to start for porting the software over. But even then, there will still be a lot of work left to do. As far as I know, Qt does not yet support MS-DOS (for either 16-bit or 32-bit systems). Thank you! -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] "Test." -- does that come from FreeDOS?
Hello Louis Santillan, hello Jack Browning, seems to be fully functional, i.e., all the builtin commands appear to work normally. When I go to run the BIOS updater by typing the .exe's file name and hitting return, however, the only thing that happens is that the word "Test." is printed to the console. The updater then exits without doing anything else. Does your BIOS come with a "Firmware Update" BIOS Boot Option? If it does, it should provide you a File Manager to select files from the USB drive and verify that the selected file is actually an applicable firmware update. Even if the file is just an EXE, the "Firmware Update" File Manager is smart enough to look into the file and extract the BIOS update. Is this the 3521A16.exe file you are referring to? https://www.dell.com/support/home/fi/fi/fibsdt1/drivers/driversdetails?driverid=p1m11 It seems that there is indeed a DOS portion _and_ a Windows portion to the executable. The DOS portion actually uses a DOS extender to set up and run 32-bit code under DPMI (COFF, starting at offset 0x5000). This 32-bit code is where the "Test." message is apparently coming from. Presumably there is a way to get the DOS portion to actually do something useful, but I am not yet sure how. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Though I wonder why I wasted so much time since it's inferior to the 8086 OpenWatcom build. I guess I still appreciate Turbo C++ for what it is. I really need to take a look at why it's running out of memory Sorry for the late reply! Actually I will not be surprised, if the Open Watcom-compiled nasm was simply more efficient memory-wise. (At the very least, Open Watcom is known to use a more efficient function call interface by default, so there is that.) Another possibility is that the Turbo C++ version was triggering some memory corruption bugs which was causing spurious "out of memory" errors. Though I sure hope that was not the case. (kernel.asm) or maybe even look into using overlays (which I'm not familiar with at all). At least it does normally work, for comparison, in case anyone wants to improve it. (Me, I am not familiar with Turbo C++ overlays myself either --- perhaps someone else on this list is. I suspect that, to use overlays properly, one will have to know a bit more about the general control flow of the program, i.e. nasm, to guide the splitting of the program code.) Thank you! -- https://mastodon.social/@tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos 1.2 move, copy & xcopy
Hello Ralf Quint, Will try to take a closer look a bit later this evening. One problem here is what I mentioned a lot of times in the past but always got scoffed at is that these are highly technical apps but do not have any proper technical documentation. And they are typical examples of where "the documentation is in the source code" just doesn't work to understand the inner workings, its limitations and hence being able to fix and/or update the program. I see that Microsoft did publish a "Microsoft Extensible Firmware Initiative FAT32 File System Specification" --- it should give us a (better) idea of the requirements that dosfsck is working towards. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Quick FreeDOS 1.3 Live CD Poll
Hello Jerome, Actually I am also curious to know what mechanism you will be using to limit access to internal hard drives. (I suppose it should be possible to use LASTDRIVE= in a config.sys file to make the hard drives invisible from DOS's view. But the hard drives will most likely still show up if a program looks for them through the BIOS.) Hiding and protection of the drives is handled by the CD boot loader SYSLINUX / MEMDISK. It is a simple option for configuration of menu that appears when the disc is booted. It does however work and when activated prevents FreeDOS from seeing or access the internal drives(s). For all purposes, drive C: no longer exists and won’t reappear until the system is rebooted. Thank you for the explanation! This sounds like a cool way to implement the mechanism. :) -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Quick FreeDOS 1.3 Live CD Poll
Hello Jerome, Yes. Prevent access to internal hard drive. No. Allow access to internal hard drive. Neither. Instead, include in boot menu to select either. People have been getting used to non-HD boot media enabling repairs, which typically means changing something on the HD. Disabling that entirely just seems wrong. I think I can second that --- i.e. include two kinds of "Live CD" modes in the boot menu. Actually I am also curious to know what mechanism you will be using to limit access to internal hard drives. (I suppose it should be possible to use LASTDRIVE= in a config.sys file to make the hard drives invisible from DOS's view. But the hard drives will most likely still show up if a program looks for them through the BIOS.) Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Program installation from multiple floppy disk images
Hello bob olbrich, DOSBox has the imgmount command for this type of installation. Have I missed an equivalent utility? One thing you can do in QEMU is to mount an initial floppy image as A: or B:, then use the QEMU Monitor to "remove" the image and "insert" another image in the same "drive", as you would on a real PC: (qemu) change floppy0 next.img You will need to enable the QEMU Monitor (e.g. -monitor stdio) to do this, of course. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, Using the above command line, the resulting size of tinyasm.exe is 27,200 bytes. With the DJGPP-hosted tools, I'm getting 45 kb. Is that correct? Or do you have newer libs? Sure, after UPX, it's about 27 kb. Either way, quite nice! Ah yes, I have updated the gcc-ia16 toolchain on my end to fix a problem with the -mnewlib-nano-stdio switch --- I hope to make a new release of the toolchain some time soon. The compiled tinyasm.exe is 27,200 bytes without applying upx compression. Thank you! -- https://github.com/tkchia tinyasm.exe.bin Description: Binary data ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, I for one would like to know how you wrote the makefiles for nasm --- I have not managed to get a 16-bit build working using Watcom. Okay, I think I've done enough fiddling to be worth sharing. So here it is (lacking any better place for us): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ Further testing and contributions are welcome, of course. Thanks! This looks like ... a rather major revamp of the makefiles. :-) It seems that the precompiled nsm09839.zip binaries in iBiblio were built with Microsoft C, most probably using Makefile.ms7. And the makefile has this...: # Compile for a 286, ain't nobody using an 8086 anymore CC = cl /c /Oz /AL /Gt256 /G2 /I.. # MSC 7.00 I guess this explains why these particular binaries are 186+ only. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, ia16-elf-gcc -mcmodel=small -Os -mregparmcall -mnewlib-nano-stdio \ tinyasm.c ins.c -o tinyasm.exe What is the resulting size of the .EXE with your build? (He said it uses at least 128k RAM, right?) At least for development and Using the above command line, the resulting size of tinyasm.exe is 27,200 bytes. I can sort of understand why Mr. Oscar did not try to include upx in the build pipeline: it is (I think) not very possible yet to build upx itself on a small, 16-bit machine. Hello dmccunney, Er, how much do we actually *care* about EXE size on disk? Even folks going old skool and trying to run on 808X CPUs are likely to have decent HDs.. (Is *anyone* still trying to run DOS (MS/PC or FreeDOS) and DOS apps entirely off of 360K floppies?) In that case, UPX may Well, I guess we are simply obsessed with code size. :-) I think generally it is OK to try making programs as small as possible, as long as it does not add too much inconvenience. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Rugxulo, BTW, what is the proper way to build Tinyasm with IA16-GCC? Is there a specific set of switches you use? Or have you not tested (much) with it yet? The bare minimum is to enable the "small" memory model (separate text and data segments), like so: ia16-elf-gcc -mcmodel=small tinyasm.c ins.c -o tinyasm.exe or i16gcc -mcmodel=small tinyasm.c ins.c -o tinyasm.exe To really crunch down the size, you can add some options to turn on optimizations and use a more efficient function call interface: ia16-elf-gcc -mcmodel=small -Os -mregparmcall -mnewlib-nano-stdio \ tinyasm.c ins.c -o tinyasm.exe (I have updated my build-ia16 scripts at https://github.com/tkchia/build-ia16 to build tinyasm using ia16-elf-gcc with my above "recommended" options.) No, I have not really tested the ia16-elf-gcc version very much. But I think ia16-elf-gcc + newlib-ia16 is actually a bit easier to work with than DeSmet C (the DeSmet runtime's C89 support is still rather incomplete and buggy, at least for now). of terminology. But it's missing "[var+BX]" Effective Address support. Also, "MOV AX,..." (etc.) instructions use the bigger, non-optimal encodings. I haven't quite identified some other quirks yet (beyond simple stuff like hex number syntax [0Ah not supported], quirky "mylabel: dw 5", seg overrides only at beginning of line, etc). Well, perhaps there are ways to fix the support for these things in tinyasm... doing that tomorrow. The makefiles are messy, and I'm no make expert, but they should both be 100% reproducible (if anyone is honestly interested). If I don't find any obvious problems, I'll probably I for one would like to know how you wrote the makefiles for nasm --- I have not managed to get a 16-bit build working using Watcom. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Tinyasm vs. NASM
Hello Masloch, hello Ruxgulo, recently, and I noticed that the (in)famous 16-bit NASM build from 2005 of 0.98.39 didn't seem to run properly. (But that could be an emulator bug. It runs fine under QEMU. I know 8086tinyplus can't handle 186+ ENTER/LEAVE properly.) If the 16-bit NASM uses 186+ instructions, that's a bug (or possibly wrong option?) on the part of the compiler. I did a quick disassembly of the precompiled nasm.exe and ndisasm.exe in nsm09839.zip, and indeed --- for some reason --- they were built to use 186+ instructions such as `leave' and immediate pushes. So perhaps it will be good to try to rebuild this version of nasm, for the 8086. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A neat find on /r/asm
Hello Random Liegh, https://github.com/nanochess/tinyasm/ Brand spanking new, targets the 8088. It can be built with desmet-c, but there's a precompiled binary included in the github repository. Thank you for the news. I have found some issues with the assembler --- I will be submitting some patches to fix them --- but it seems it will come in useful. -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] [release] Dr. Mind v1.0
Hello Mateusz, http://drmind.sourceforge.net Well, all I can say for now is, it works and is really cool. :-) Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] PXE freedos and img file
Hello all, But i can't figure out how to add my .exe files to this FD12LITE.img file. >> Any ideas ?> On a Mac, you can just mount that img file by double clicking it in finder.> On Linux, you can mount it through the loop back device.> On Windows, you may require additional software to mount a filesystem image. IDK. I don’t use widows. A quick note: the actual filesystem itself, where the extra files should go, starts at offset 32256. (Offset 0 is the master boot record and partition table.) So on Linux it is necessary to specify the offset to mount from, e.g. # mount -o loop,offset=32256 FD12LITE.img /mnt ... # umount /mnt I _think_ a Mac would be able to automatically parse the .img file and find out where the filesystem is --- though I am not sure. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installing with QEMU
Hello Joseph Norton, I’m trying to install FreeDOS with QEMU, and I get as far as formatting the hd, then, the installation says it can’t find the package files. I used the example in the Using FreeDOS Ebook, but, I did have to create the “freedos.img” file, which was not covered. Did you run the following command to create freedos.img (as suggested by the e-book)? qemu-img create freedos.img 200M The idea is that freedos.img will act as _the_ virtual "hard disk" which you will install FreeDOS _to_. And the installation medium which you install FreeDOS _from_ is simply the CD-ROM image (such as FD12CD.iso) you downloaded earlier. If you start QEMU the right way, the "hard disk" will have drive letter C: and the CD-ROM image will have drive letter D:, and you will be booting the virtual machine from the CD-ROM image to do the installation. My suspicion is that you were starting QEMU in such a way that it was erroneously formatting the installation medium. (Alternatively, there is a different set of instructions at Wikibooks, which I have been using, for installing FreeDOSin a QEMU VM: https://en.wikibooks.org/wiki/QEMU/FreeDOS .) Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Preloading text files in C
Hello Nils, hello Ken, ptr_array[0] = malloc(size_of_textfile); copy_to(file0, ptr_array[0]; ptr_array[1] = malloc(size_of_textfile); copy_to(file1, ptr_array[1]; ... Can I still use fgets() on these pointers once the file has been loaded there? No, fgets wants a FILE *, which is a pointer to a stream, not a char *. If you are not able to rewrite the program to process the buffer directly, forgetting about fgets(), there is fmemopen() which returns a FILE * given a string. But it may not be implemented in your C library. https://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html I just found that the Newlib library as included in the gcc-ia16 toolchain does happen to implement fmemopen( ) (and several other POSIX functions as well). However, Open Watcom's C library does not have this function. I suppose, if a `FILE *' is not absolutely needed, then one can use strchr( ), strcspn( ), etc. to slice the input up into separate lines, without writing a lot of code. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] aefdisk/masterbooter open sourced
Hello Geraldo, First of all, hope you all had a great christmas time! This is interesting. It seems the aefdisk sources are using some strange syntax extensions which I have not seen before --- perhaps these are supported by certain versions of tasm? Dunno :( But I opened a ticket for Nagy Daniel (https://github.com/nagydjol/aefdisk/issues/1) Asking his tasm/borland c compiler Maybe we could integrate it on freedos repository or even deprecate our fdisk in favor of aefdisk in future Thank you! I am also curious to know which version(s) of tasm can be used to build the program. I have meanwhile also made a first-cut attempt (https://github.com/tkchia/aefdisk) to "downgrade" the assembler syntax used, so that the program can be built using other DOS assemblers. However, I still need a way to verify that I have done the syntax conversion correctly. Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] aefdisk/masterbooter open sourced
Hello Jerome, hello Geraldo, Seems to require borland c/tasm Unfortunately, aefdisk won’t compile under TASM 4.1. Tried. But, It throws a couple errors and warnings. This is interesting. It seems the aefdisk sources are using some strange syntax extensions which I have not seen before --- perhaps these are supported by certain versions of tasm? For example, there is ends rather than say _DATA ends to end a segment definition without specifying a segment name. There is also MBRloader label rather than MBRloader: to label something that is not a procedure. (I am copying this mail to freedos-devel, since I believe that will be a more appropriate venue.) Thank you! -- https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
