Hi, I'm not sure how you're missing the point here nor why this is such a big deal to you. This is very small potatoes.
On Tue, Sep 15, 2015 at 10:16 PM, Michael Brutman <mbbrut...@brutman.com> wrote: > > Disclaimer: I understand that once I release something into the wild, there > is not much I can do about it. You explicitly chose GPLv3, yet I didn't even need it! I didn't even recompile nor modify anything. I did not break your licensing agreement. > I see two problems with the two included mTCP programs: > > 1. I took great care to write user documentation for my programs and the > DHCP.TXT and FTP.TXT files should be included with the executables. Face it, there was no way I was going to forcibly include (too many) optional files that aren't require to run the existing setup. This is not even a full floppy, it's a placeholder for (unspecified) future work. You could legitimately argue that I have plenty of free room (for now ...) to add them, but that does not mean it is strictly necessary to function. > The README.TXT file is kind of important too - it gives the requirements, > features, and where to go for help. Distributing executables that were > originally part of an ensemble without the general README.TXT or the program > specific instructions is king of wrong. No, because they aren't strictly needed. I never needed them for my uses in recent months, and as mentioned, I was the primary tester (by far). It worked fine for my needs (almost). > 2 - The file sizes for DHCP.EXE and FTP.EXE are different than the versions > that I compiled and distributed. I am guessing that you ran them through > some sort of image compressor. I can't tell though; did you include the > batch files or a makefile that you used to process the original > executables? Like I said, I don't even remember, and clearly it's been over a year. Certainly, in hindsight, there isn't much use (and maybe a wee bit of discomfort, in rare cases), so I would avoid that if possible (which is still reasonable for most use cases). Again, I did not modify anything, just repacked with UPX for higher compression. The fact that some ancient machines (sorry) and slow emulators take ages to load isn't my problem. I'm not denying the issue, but it was not important enough for me to even pretend to notice until you mentioned it. > Your version of FTP.EXE takes 1 minute and 46 seconds to load and print out > the title line. > > My standard version takes 2 seconds. That's 53x faster. > > My UPX compressed version takes 5 seconds. That's 21x faster. > > Your version is 55906 bytes and my UPX compressed version is 58395 bytes. > So my original compressed executable is a little bigger, but yours is > worthless on an 8088 class machine. Given that I wrote mTCP explicitly to > support 8088 class machines, I find this kind of reprehensible. MetaDOS has never supported 8086 (nor even 186 or 286 or similar, e.g. NEC V20/V30) machines. It was never designed to run on older hardware. I'm totally sympathetic, believe it or not. But most people are not, and I can't just naively pretend that every source code is "strictly conformant", compilable with every obscure compiler under every memory model for every (sub)architecture. It wasn't my decision with most of it, so I had to live with the limitations. 386+ is hardly a deal breaker these days. Again, my main target was almost 100% strictly either QEMU or VBox and nothing else. I did not worry about further edge cases because I had enough problems to focus on already. > I suspect DHCP has the same problem; it is taking longer to run in DOSBox. > I hope the other programs are not compressed in the same way. I have used and enjoyed DOSBox for a long time, but I have only rarely tested it as an emulator of other OSes. It was designed "only for games", and I usually don't push it beyond that. By default, it has a fake DOS, max 64 MB RAM, no networking, no LFNs, "fast 486" DX2 (on 1+ Ghz host hardware), plus it hasn't even had any official releases in five years. I'm not knocking it, but it's very limited in what it supports (and you're using a third-party build, even more obscure). Please don't expect me to sympathize with every emulator under the sun, it's impossible. I like emulators, but I can't test dozens. So, for simplicity, I am explicitly focusing on QEMU and VBox. Sorry, but neither of them are anywhere near as slow as (portable, i.e. no V86 nor VT-X) DOSBox. I have booted QEMU and VBox hundreds of times over the past year, and I never saw anywhere near as drastic a slowdown as you're reporting now. Literally, it was not a significant problem by a long shot. It's your slow emulator, not UPX's fault. > Please fix this - distribute the appropriate TXT files and fix whatever > compression program you are using, or better yet, use the originally > distributed UPXed binaries. My name is still on the programs and I don't > want other people to think that I am responsible for a nearly 2 minute > startup time. I don't think you understand the point I'm trying to make. First of all, certainly I do not want to silently update the release just to fix a trivial issue that isn't even present in most emulators. There's no reason to have formal releases at all if I'm just going to make it a rolling release, constant work-in-progress. I don't think anyone wants that, and certainly I don't either. It's too tedious to do that. If you want to kick the tires further, I'm sure you can find other bugs and omissions that need fixing "eventually", but that probably won't all happen overnight. Secondly, did you not understand that this is how UPX is supposed to work? Did you not know that UPX is (roughly) GPL (with a few exceptions)? And the whole point they are trying to make is that you should always be able to unpack and repack your executables. I have not stopped you, nor can you stop me, because that was their intention from the beginning. I did not break their licensing agreement. That was the whole idea. And yes, LZMA does (especially on bigger files, e.g. DJGPP-compiled WGET.EXE) make a huge improvement. Believe it or not, I considered adding Wget to the floppy as well, but it wouldn't even fit unless unpacked/repacked! > (Wed, Sep 16, 2015 at 7:40 PM): > > I have a real simple solution ... Test more or repackage things without > altering > them so that more testing is not needed. > > My UPXed binaries are almost the same size and don't have that horrible side > effect. That's because I recognize the value of testing on a variety of > targets > and I accept responsibility for what I put out there. Did you test under QEMU? VBox? VMware? VPC? Parallels? Bochs? Or various others? Do literally any of those have the same issue? DOSBox was never officially meant to be a real emulator for things like this. If you see horrible slowdown, it's because DOSBox is intentionally extremely portable, and they just didn't care enough to optimize further for x86 host. But no, that's not a simple solution (nor is me saying "use a better emulator"). Here's a few (local) fixes: 1). Call "fetch mtcp" to grab the original  .ZIP (with .TXTs and original .EXEs). ... or ... 2a). Run (stub) UPX.BAT to unpack/repack the offending .EXEs. 2b). Grab the .TXTs from the (mandatory) source .7z archive. Is any of that prohibitive? You're also free to wait until next release and/or fork/improve/republish it yourself. ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ Freedos-user mailing list Freedosemail@example.com https://lists.sourceforge.net/lists/listinfo/freedos-user