Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
On Fri, 14 Sep 2018, Rugxulo wrote: Date: Fri, 14 Sep 2018 11:01:39 -0500 From: Rugxulo Reply-To: Technical discussion and questions for FreeDOS developers. To: freedos-devel Subject: Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease Hi, On Fri, Sep 14, 2018, 8:49 AM Seth Simon wrote: In MS-DOS 6.22, neither "if exist ::\nul echo exist" nor "if exist Q:\nul echo exist" (where Q is a drive that doesn't exist) will cause anything to be echoed. I know this is a common DOS idiom, but keep in mind that I don't recall this kludge working with XP's CMD. So it's a bit brittle (like all such similar tricks). But But in all 3 of commandg.com, commandt.com, and commandw.com, both of those commands will echo "exist". But it's not a regression because 0.84-pre2 does the same thing (the FreeCom tests were done under FreeDOS, not MS-DOS). Ah, then this is that same bug/regression in kernel 2042 (only). Try older 2041, it should work fine there. (I'm pretty sure Jeremy already knows about it.) I meant that I did the former test on an actual, real MS-DOS 6.22 boot diskette, not XP. But indeed, as you said, the bug is in the kernel- I can confirm that the 0.84-pre6 shell works as expected under the 2041 kernel. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS wiki is temporarily offline
Hi everyone An FYI that wiki.freedos.org is temporarily offline. *The short story is this:* Last month, I moved the website to a new host provider, at Dreamhost, but left DNS at my previous third-party DNS hosting service. I set up a " wiki.freedos.org" at Dreamhost, with the intention to eventually move the wiki from SourceForge to Dreamhost. But I haven't had time to do that yet. I planned to do it over the next few weeks, going live in Oct. Last week, I moved DNS hosting over to Dreamhost. This took effect over the weekend. When the DNS move happened, I think Dreamhost recognized there was already a "wiki.freedos.org" set up on Dreamhost's servers, and their automated process "helpfully" repointed DNS to the not-yet-working site. The wiki at SourceForge is still there, but it really wants you to access it via wiki.freedos.org (so you can't get there). I worked on it with a Dreamhost Live Support person, but we couldn't get wiki.freedos.org to work as DNS only, pointed at SourceForge. *Next steps:* I have a ticket in to the next level of support. If they can't fix it either, I'll update the wiki config to use the SourceForge VHOST, and update the link from the website to point there. And then accelerate moving the wiki to Dreamhost. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Translations for LSM data files.
> On Sep 19, 2018, at 4:45 AM, stecdose wrote: > > I just have downloaded the csv-file and had a look at it. It isn't as > big as I thought. > > I am going to translate the whole list to german. It will take a few > days, I have some real-life work to do, but I think I am done > translating this weekend. > > Greetings, > Nils Stec Sounds great. I look forward to receiving it. Before you begin translating, insure the program you are using correctly parsed the CSV file. This is easy enough to do. Just scroll to the last column that has the SHA hashes and verify none have drifted. I have not seen this happen in the spreadsheet program I use. But, it was reported that a couple items drift when imported into LibreOffice. Thank you, Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: [almost to announce] FD Floppy Distribution + Installer
Hi there, First of all, I am new to this list, though I am reading it for a long time now. I really like spending hours on reading topics... I don't know which is the best place for this message. As it is about development I stick to freedos-devel. Is it ok to also send to freedos-user, because in the end it will affect users when used. And maybe users have suggestions for easy usage ;) Or would it be better to wait until I have something to release and then put another message on freedos-user without the dev related stuff? I am in progress of making a floppy disk distribution of FreeDOS. I am not totally ready to publish it and more and more questions arise, this is why I write here, before doing all the work to the end and then realize it was the wrong way ;) Mainly I want encouragement or a "hey, this is not going to work like this!". The section "Desc. of Installer / Please comment" describes the installation process. I want you guys to comment on that. Do you have any suggestions on this procedure? The whole mail is spotted with questions and assumptions. I want answers and corrections ;) # why? I don't need FreeDOS on computers that have a CD-drive, for these I use more unix-like OSes (minix, linux, *bsd). I use it on 2 single board computers, an old laptop that has no CD, no LAN. I have searched for floppy images and found a post on mailing list or a bug, which I can't find right now to link it here, that asks for floppy images. Someone (maybe Jim Hall?) answered that it is possible but due to lack of demand and man-power no one has made it. # What is it? It is *not* a full blown FreeDOS installation. It is a base-system+self written installer that fits on one single floppy disk. Installer has the ability to "install additional disks". This menu-entry will, if selected, wait for floppy change and then execute a .bat file on this disk. This makes it very easy for users to build their own custom additional disks. For example a file commander (like VC) in a zip file on a disk, can be copied and unpacked by this bat to disk. # Screenshots As my message was too big with screenshots, I have uploaded em here: https://raw.githubusercontent.com/spacerace/snippets/master/screenshots/dosinst/di00.png https://raw.githubusercontent.com/spacerace/snippets/master/screenshots/dosinst/di01.png https://raw.githubusercontent.com/spacerace/snippets/master/screenshots/dosinst/di02.png https://raw.githubusercontent.com/spacerace/snippets/master/screenshots/dosinst/di03.png https://raw.githubusercontent.com/spacerace/snippets/master/screenshots/dosinst/di04.png https://raw.githubusercontent.com/spacerace/snippets/master/screenshots/dosinst/di05.png These screenshots were taken using dosbox on linux. # Description of Installer / Please comment It is a menu based design, rather than the step-by-step design like MS-DOS installer uses. I wanted to have this for most flexibility and easy usage. As you can see on screenshots I have implemented it with these steps: * Setup Keyboard * Setup HDD (executes fdisk, asks for executing format C:, asks for sys C:) * Configure (Date, Time, DOS-Folder, xcdrom, ctmouse, himem, emm386) * Do the installation * Run A:POSTINST.BAT for easy adding stuff by user * Additional Disks (executes bat on another disk) Every step may be omitted. For example, if you already have a properly set up hard disk or if you don't need a keyboard driver (for default EN keyboard). Due to "it was too complex and is not needed by me up to now" I have fixed every possible drive-selection for destination to C, for source to A. I have never needed something else, if you think else, please write back. I also have added a few command line options, as you can see in last screenshot. /AUTO will do a default installation, totally automatic including fdisk,format,sys,copy,... /COMPATVIDEO forces the installer to use VIDEO BIOS rather than direct video card access. This is useful if you have a not 100% IBM compatible machine, but makes video out notably slower. /MONOVIDEO forces black/white color scheme, if you have problems reading text on a mono display. /README is the same as pressing "F1" in installer, it pages A:README.TXT /? /H /HELP is the same, prints help like seen on last screenshot. # Packages I have taken the base-packages (zips) and removed everything unneccessary in these, only leaving the bins in zip. These packages are on disk right now: APPEND ASSIGN ATTRIB CHKDSK CHOICE COMMAND COMP CPIDOS CTMOUSE DEBUG DEFRAG DELTREE DEVLOAD DISKCOMP DISKCOPY DISPLAY DOSFSCK EDIT EXE2BIN FC FDAPM FDISK FDXMS FDXMS286 FIND FORMAT GRAPHICS HIMEMX JEMM KERNEL KEYB KEYB_LAY LABEL LBACACHE MEM MIRROR MKEYB MODE MORE MOVE NANSI NLSFUNC PRINT RECOVER REPLACE SHARE SHSUCDX SORT SWSUBST TREE UNDELETE UNFORMAT XCOPY They makes 1.240k in total. cdrom driver is still missing on floppy (not worked on this yet). command, format, sys, mkeyb and pkunzip are on floppy unzipped. This takes some space. I have approx. ~100k fr
[Freedos-devel] Fwd: Re: Larger buffers in Watcom
Aaah now I get it. Thank you. I should have written the third line with dec 16384 = hex 4000 also and I would have seen it. I guess a compiler that does not complain about about an integer overflow leads to quite shitty code. Or did he ignore compiler warnings? I am using Borland, this is what happens with it: * having 0x14000 without UL at the end, warns about too big for an int * sending 0x14000UL to a function that takes "unsigned int" complains about that uint is too small for ulong. So I assume the size_t thing in *alloc is totally correct, the user had problems at a lower, language related, level... On 09/19/2018 10:51 AM, Mateusz Viste wrote: On Wed, 19 Sep 2018 10:44:14 +0200, stecdose wrote: HOW does a 16bit truncate limit to 16384bytes? b1 b0 (byte 1, byte 0) b2 | | (byte 2) | | | decimal 81920 = hex 014000 decimal 65536 = hex size of size_t = 2 bytes 16k is far less than 64k, why does it truncate to 16k? why not 64k if greater than 64k? TK Chia tried to allocate 81920 bytes (0x14000), while malloc accepts an unsigned short (16-bits) only. Hence only the lowest 16 bits of 0x14000 were actually fed to malloc(), ie. 0x4000, that is 16K. Mateusz ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Larger buffers in Watcom
On Wed, 19 Sep 2018 10:44:14 +0200, stecdose wrote: > HOW does a 16bit truncate limit to 16384bytes? > > b1 b0 (byte 1, byte 0) > b2 | | (byte 2) > | | | > decimal 81920 = hex 014000 decimal 65536 = hex size of size_t = 2 > bytes > > 16k is far less than 64k, why does it truncate to 16k? why not 64k if > greater than 64k? TK Chia tried to allocate 81920 bytes (0x14000), while malloc accepts an unsigned short (16-bits) only. Hence only the lowest 16 bits of 0x14000 were actually fed to malloc(), ie. 0x4000, that is 16K. Mateusz -- FreeDOS is present on the USENET, too! alt.os.free-dos ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Translations for LSM data files.
I just have downloaded the csv-file and had a look at it. It isn't as big as I thought. I am going to translate the whole list to german. It will take a few days, I have some real-life work to do, but I think I am done translating this weekend. Greetings, Nils Stec On 09/11/2018 10:40 PM, Jerome Shidel wrote: Hello again everyone, Thanks to one of the community members, we now have translations in French and Turkish on hand for all of the FreeDOS packages in the repository. These translations will definitely make it into the upcoming 1.3 release and be supported by FDIMPLES for package browsing and installation. Eventually, I’d like to see the online software repository support native language pages as well. But, that will probably have to wait a bit. If you would like to see support for any additional languages, please don’t hesitate to provide them. I know it is quite a bit of work. But, I think the non-english speaking users will appreciate the effort. To get started. To prevent duplicate effort, let us know what language you are going to provide. Then, fetch the latest package list CSV from the official software repository http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.2/listing.csv Simply translate the Description, Summary and Keyword fields. When your finished, let us know. We will be glad to include them. Just remember, the deadline for language submissions will be October 31. Thanks again. Jerome ___ 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] Larger buffers in Watcom
I recently stumbled across this problem with Borland C (Affects all borland 16bit C compilers, TC, BCPP). The problem of a 2byte size_t farcalloc was the solution to allocate a 256k buffer in my case. But a part of your text gives me a question On 07/29/2018 05:17 AM, TK Chia wrote: Actually, I just found that both malloc( ) and calloc( ) do not work for the purpose, and we _do_ need to use something like halloc( ). I double-checked the compiler output (using `wdis test.o') for the malloc( ) call under the huge model, and found that it actually clips the size to a `size_t', and `size_t' is a 16-bit integer type even for the huge model. I.e. malloc(81920) only allocates 16384 bytes. HOW does a 16bit truncate limit to 16384bytes? b1 b0 (byte 1, byte 0) b2 | | (byte 2) | | | decimal 81920 = hex 014000 decimal 65536 = hex size of size_t = 2 bytes 16k is far less than 64k, why does it truncate to 16k? why not 64k if greater than 64k? Maybe you can instruct your compiler to warn about integer overflows. I changed my codestyle on 16bit-int-platforms to use for example 0x1ul (for unsigned long). If I have a value greater than 0x and not have added "ul", compiler warns and I get what happens. This helped me a lot... Or did I get something wrong? (I assume we are rediscovering well-known programming techniques from the 80s here...) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
