-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DIR /2 file/directory display misalignment #69
Comments
I uploaded my build to https://pushbx.org/ecm/test/20240722/command.com Did you try it on a shsucdx-redirected drive? My test is from the same file system as described in #63 |
Ouch, compared the same files instead your hg version with mine, no wonder they were the same... There seem to be some significant changes between your version and mine. When reformatting your file with clang-format, it breaks the file, so that it does not compile anymore. Makes comparing the files not exactly easy... I'll try with another clang-format version, but under MacOS I currently only have version 18.1.8 available. However, I think I got your version to work by doing the following change:
|
That seems to fix it, yes. Any idea as to the root of this difference? (I know I didn't pick your reformat commits several months ago but you mentioned there's non-formatting differences as well.) |
For example I stripped out all the CDOS ifdefs and removed support Concurrent DOS. If there are functional differences I have to look more sharply. |
That with the no timestamp display will probably also affect my version. I first have to find out how to create a file with the timestamp set to zero. |
The blame shows it was part of the following commit by me: |
May it be that you incorporated this by hand and missed the trailing space inside the strings? |
Oh, looking at the commit's diff in 2a20b1a you did insert the blanks. I just missed that bit. As for how to create a file with zero date/time you can use my NASM script bootimg (also requires the lmacros collection), which defaults to zeroes for the date and time. Here's an example scriptlet using it:
|
Yes, I applied this earlier today but that hunk didn't apply cleanly. So I manually did the same change, or so I thought. Fixed in https://hg.pushbx.org/ecm/edrdos/rev/f184213d988f |
The |
Thanks, this worked. I simply used bootimg to create a floppy with a few files on it. Two-column mode should now align correct 23aa224. I did not test test the display of long filenames yet. According to the source, there seems to be some support for it... |
please excuse my interference, but i can't help myself wondering why each of you works on his own copy of edr-dos, instead of joining forces and work together on the same repo ? from a user PoV its kinda confusing - "which one should i use, which one is better?", and having to backport patches all the times seems to be an awkward situation as well. |
Yes, the shell supports it but you need doslfn or a redirector with LFN support to use it. I just tested in dosemu2 (FreeDOS kernel) and it seems to be fine with this update. I'll pick it later today for my repo. |
Hello @rofl0r, no interference at all :) I can understand that from a user perspective it is a little confusing. In large parts we are working together, albeit there are two separate repositories. We have for example some kind of double-checking. Changes that go into this repository are regularly checked by @ecm-pushbx before importing it into her repo, and this is also largely true for the other way around. While there should not be much user-visible differences apart from @ecm-pushbx providing single-file versions of the kernel, the projects differ in having completely different build systems, and they are utilizing different version control systems. While this repo is based on Git, the ecm one is based on Mercurial. Having this repo gives us a public issue tracker and some "range" by being on Github. The Mercurial repo seems to be tightly integrated into ecm's workflow, and the commit log is much more accurate than the one for this repo (I am a bit sloppy in this respect). |
I hope I won't sound nagging, but would there be any chance for this single-compressed-file version to land in your repo here? That's the one thing I am looking forward to before integrating the EDR kernel in the SvarDOS core. :) |
Yes, if you eagerly await it I will prioritize this. If I understand it correct, I can not simply import it from @ecm-pushbx repo, because this kernel would not be bootable by the bootsector provided with the SYS command. But I will have a look at it shortly... |
Replying to @rofl0r:
*his or her own copy
Well, @boeckmann already replied to parts of this. We do review one another's contributions for the most part, except things like the build system that I do not wish to carry over and single-file load which hasn't landed in the SvarDOS repo (this repo) yet. I recently replied to someone else per email (had to get home to access my sent mail), which also describes the situation some:
Replying to @boeckmann:
Exactly, we do work together to some degree, despite the two repos.
Yes, I'm still using a variant of the original build scripts which run in DOS as batch files, except for the kernel post-processing to create the single-file executables and the kernel's trace listing files.
I don't know about this; I do use the hg changeset revisions hashes and "amount of ancestors" in some places (eg lDebug
That much is true! Much like for FreeDOS Debug I also imported the old version history into the EDR-DOS repo, to be able to reference the earlier versions, back up to the original OpenDOS 7.01 Machine Readable Source release. (I think there was more fine-grained WIP patches available which I didn't all import. But it is something.) |
It's nice to be appreciated =)
This is not true actually, the EDR-DOS load protocol and (its basis) the FreeDOS load protocol are both able to load all four variants of the single-file kernel that I provide. The differences between the use of the files are grouped into whether the files use lDOS iniload ( I have documented the FreeDOS load in the lDOS boot manual. Do note the assumptions section as well.
The part on the EDR-DOS load protocol describes the traditional differences from FreeDOS load. The dl versus bl question is doubly obsolete, as lDOS (both iniload and drload) does not care, and recent FreeDOS boot loaders do provide both dl and bl. The ds:bp versus ss:bp is relevant, but there is little reason for any loader not to provide ss:bp. The differing load and entrypoint addresses are of little concern for lDOS drload, and can be safely ignored for lDOS iniload if the kernel file is at least 32 KiB in size. The difference between iniload and drload is that iniload can be loaded as a lot of different kernel formats, whereas drload requires being loaded as a FreeDOS or EDR-DOS kernel. All of my single-file EDR-DOS kernels may be loaded using the FreeDOS or EDR-DOS load protocols; the iniload ( |
Tested and picked in https://hg.pushbx.org/ecm/edrdos/rev/c3a7e99c10bb - thanks! |
That much said on the single-file load, you will have to reference or import at least some files from lmacros, ldosboot, kernwrap, and for the compression also the inicomp stage plus at least one method's packer. scanptab and bootimg may also be needed, as do dosemu2 or qemu + DOS files to run the decompression test (required to gather the amount of dots for the progress display if it is enabled). |
For the qemu test run mtools is needed as well, I think. |
For the start I relocated the zero-uncompression code into the deblocking buffer, to compress the whole DRBIO. If you may have a look at it. Shrinks the BIO by around 11K. My goal is to have this running at least in the zero-compression only case (no exomizer et. al.) without depending on kernwrap etc. |
@mateuszviste thanks for the appreciation. Would it be ok for the combined file to initially be around 50K in size? This would be without "sophisticated" compression utilized. |
It would be cool, yes. My primary goal is not to use more disk space than what we have with the FD Kernel. The UPXed FD kernel is smaller (45K), but 5K feels like an acceptable cost for a beta-test run ;-) I assume that after a "real" compression is applied (Exomizer or what not), the EDR kernel will be at least as small as the FD kernel. |
46 kB with LZMA-lzip and the drload entry:
|
That's interesting! Any idea why it's slightly bigger than the UPXed FD kernel? Does this EDR kernel build come with some extra features, like LFN or such, or is the C-generated FreeDOS kernel machine code simply more compact than EDR's hand-crafted assembly? Also, do you think such LZMA-packed kernel likely to noticeably inflate the boot time on a 8086-era PC? |
Not sure. The EDR-DOS kernel supports some nominally "LFN" functions but only actually with SFNs; the functions are implemented to allow returning 38-bit file sizes for its FAT+ support. That does eat some memory. My depacker is likely not as optimised as UPX's. It needs about 3 kB for the inicomp stage.
Yes, the depacking may need several minutes. This is a reason for the depack progress indicator lest the user thinks the machine hangs. In a blog post I tested depacking LZMA-lzip packed lDebug on the HP 95LX, which runs a NEC V20 at 5.37 MHz: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2023/0321_cpu_performance_comparison#the_hp_95lx The corresponding ldebug.com file (includes lDOS iniload) is 70 kB, the compressed payload is 62 kB, and the uncompressed .big image is 108 kB:
So the 3 minutes estimate is too high for depacking EDR-DOS because the kernel is smaller than lDebug r5, but it is too low because an 8088 is slower than the NEC V20. |
I am probably committing blasphemy by asking this... but is is possible to disable FAT+ support at build time, or is it hardwired into the overall kernel design? My understanding is that FAT+ is an improved FAT32 that supports files of up to 256G. I wonder if anyone really uses that.
Ah, so it's similar to my experience of using upx --lzma... At some point I was happy to compress my programs that way, until I realized that it added a runtime overhead of between 30s and a minute on my 8086. :/ That being said, the lzma decompressor is relatively large, so given the modest size of the kernel, perhaps a weaker compression algorithm with a more compact decompressor would be actually better.. the "no zeroes" version of the kernel being less than 64K, maybe is there a more trivial (de)compression method better fitted for tiny (16-bit addressable) contents? |
FAT16+ technically exists too, but needs large cluster sizes (supported by EDR-DOS itself, FreeDOS, and lDOS fork of MS-DOS v4). I'd rather not make FAT+ optional but it can be done.
In fact UPX with
My depackers all need >1024 Bytes for their inicomp stages although these are capable of both compressed and decompressed sizes beyond 64 KiB. So it is possible to optimise them some if you do not use them for large files. Feel free to poke around the source texts! |
The issue went a little off-topic. The original bug seems to be fixed? Then I could close this. |
just out of curiosity -- is there any practical reason to use EDR-COMMAND instead of SvarCOM? Like better compatibility, smaller footprint, some features, etc - or is it more a matter of personal preference? |
Looks like EDR-COMMAND contains a ton of compatibility stuff, some even originating from Digital Researches Concurrent etc. I maintain this mainly for documentation purposes, and use EDR COMMAND only as the default shell for the Github action disk images, so I can test if it still works. I will not put much effort in improving it apart from fixing bugs reported. Honestly, under DOS I prefer 4DOS. |
With the update from 2a20b1a
Picked into https://hg.pushbx.org/ecm/edrdos/rev/f54f5656a8c8
Look at this image of one of the FreeDOS test .iso CDs:
The text was updated successfully, but these errors were encountered: