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 [2013] .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
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
