history.txt

一些初级的网络编程

Porting aPLib decompresion routines by Jibz to 16 bits by METALBRAIN

        I haven't Internet conexion at home, so I can only connect from my
  University from Monday to Friday (only a short while in the morning, except
  Mondays, when I can also connect from 14:00 to 16:00), and some weekends
  from a friend's house (in summer is much worse).


28-10-98   to  12-11-98
        I wanted to use aPLib v0.17b in my small game KOM, but all code is 32
  bit, and KOM is a 16 bit project, so after several failing tests, I started
  writing 16 bit version of NASM assembly routines, cleaning all C connection
  protocol code and replacing string instructions and those that accessed
  memory through [esi] and [edi] with 16 bit emulation routines. I started
  putting them in smalls programs with fixed names for infile and outfile.
  After fixing a bug, they started to work. Then I got aPLib v0.18b, and
  updated my routines, and kept improving my test programs. Then finally
  came out aPlib v0.19b, so I updated my routines once again, and started to
  work more seriously, in order to offer my 16 bit port to Jibz.

14-11-98    Saturday
        Finally wrote a depacker capable of reading filenames from arguments.
  Infile can't be greater than 64Kb, and no test is made about memory, so if
  outfile is too big, it could collapse memory. My deppacker broke a file,
  and I couldn't find any bug on it. I made some tests and found out a bug in
  aPPACK itself. Oops. It also happens to previous versions. Jibz must be
  informed about it...

15-11-98    Sunday
        Cleaned the code a bit, eliminating some redundances.

16-11-98    Monday >
        I send Jibz first version of DEPACK and DEPPACK (948 bytes), and
  also tell him about aPPACK bug.

20-11-98  > Friday
        I got response from Jibz. He has found a bug in my routines, and he
  has optimized both DEPACK and DEPPACK a lot. I look at his code and feel
  really dumb. Some optimizations are so obvious...

22-11-98    Sunday
        I make first version of DEPPTINY. It's the same that DEPPACK, but
  without error nor usage messages. My first goal was to make it under 700
  bytes (that was the size of the tinyest decompressor I knew before mine
  arrived), and as firstly I got it in 519, I played a bit to make it under
  512 bytes (just one diskette sector). It ends up being 507(?) bytes long.

23-11-98    Monday >
        I send Jibz first version of DEPPTINY (507). At home I start coding
  next DEPPACK version, featuring use of all available memory to be able to
  uncompress any file which fits in low memory.

24-11-98  > Tuesday
        Jibz sent me a very optimized version of DEPPTINY (437). I can't
  believe my eyes. He wiped away 70 bytes!. I'm really amazed. And code is
  also cleaner, as he removed my dirty self-modifying code trick. I study his
  optimizations. Curious. He got rid of most variables. I look at the code
  and I'm able to clean 6 bytes from it. Now I feel great, my spirit rises
  and continue coding v0.2 of DEPPACK, but I can't get it working.

25-11-98    Wednesday >
        I send Jibz my optimization of DEPPTINY (431) and I asked him about
  my problem (thought I wasn't too clear about it). In the evening I study
  the code debugging it and fix my problem alone, with another dirty
  self-modifying trick.

26-11-98  > Thursday >
        I recieve Jibz's last work on DEPPTINY. I send him the very first
  version of DEPPACK v0.2 . At home, I look his DEPPTINY. Incredible!. He
  did it again! He killed 32 more bytes, leaving it in 398. Now some
  optimizations are really weird (such as order modification), but they work
  perfectly.

27-11-98    Friday   to   29-11-98  Sunday
        I port some optimizations from last DEPPTINY to DEPPACK. I think
  he'll send me something next Monday, so I put NASM, aPACK, and some test
  files in my diskette, together with last DEPPACK.

30-11-98  > Monday >
        As I expected, Jibz has played with DEPPACK v0.2, optimizing it (he
  cleaned 3 bytes from DEPACK core) and has eliminated my self-modifying
  part (he really seems to hate them), but he hasn't implemented
  optimizations from last DEPPTINY, leaving them to me. Easy work, as it was
  already done. I spent half an hour with it and apply his last optimizations
  on my last version of DEPPACK (876), and send it back to him.

 1-12-98    Tuesday
        I apply the optimization of the core to DEPACK and DEPPTINY. Works
  perfectly, and now it's only 395.

 4-12-98    Friday
        I haven't recieved nothing yet, but I can see in his page that he's
  working in aPLib v0.20b. A long weekend awaits me, because there's no
  class next Monday and Tuesday.

 6-12-98  > Sunday >
        I spent morning with a friend, and I could connect a little while.
  The response was there, so I took it. He tells me he's porting my routines
  to 16 bit C compilers, Borland ones are working and others are on the way.
  In the afternoon I look carefully last optimizations applied to DEPPACK
  (871): very instructive. They save a lot of bytes to uncompressed program,
  but after compresion he only won 6 bytes. I feel inspired and remove 7
  bytes to uncompressed program, that become a gain of 16 bytes after aPACK
  compression. I feel very proud because one of the bytes I've killed was
  inside DEPACK core, so in the evening I send Jibz the whole pack from
  other friend's home: DEPACK, DEPPACK (855) and DEPPTINY (394). I thought
  they were going to be last optimizations before aPLib v0.20b release, but
  I was completly wrong.

14-12-98    Monday
        I've finished classes today, and there's been no feedback from Jibz
  yet, but I must go to University on Wednesday and Friday. Managed to cut
  2 bytes from DEPPTINY.

15-12-98    Tuesday
        Got an idea: Cleaned 4 bytes from DEPPTINY and 2 from DEPPACK.

16-12-98    Wednesday >
        Got another idea: Cleaned 2 bytes from DEPACK core, so I send him
  again the whole package: DEPACK, DEPPACK (851), and DEPPTINY (386), not
  knowing if it will be there in time or not...

18-12-98    Friday
        Went to University, but computer rooms where closed. AAAAAARGH!

20-12-98  > Sunday
        Finally could connect, and catch Jibz's response. A new smaller
  version of aPACK leaves DEPPACK in 815 bytes. Great! I cut 4 more bytes
  from DEPPTINY and 2 from DEPPACK. Start coding DEPPACK 0.3b, capable of
  decompressing files of any size. I thought that "57300 bytes lookback"
  meant that only 57300 previous bytes were needed to unpack, but it I tried
  to use 64K and it didn't work at all. I spent the night trying to find
  bugs, and was not sure if it was possible to do what I wanted to do. At
  5 a.m., tired and frustraded I leave it for impossible.

21-12-98    Monday
        I debug the depacking of some files to see the values it can take.
  I set the limit in 128K and finally progressive-write got running! I make
  progressive-read (much easier), and test the resultant DEPPACK v0.3 in
  some extreme files. I fix some bugs and down the limit to 96K, and it
  still works. I make the DEPPTINY v0.3 from this, but it's too big, and
  can't get it under 512 bytes, so I'm leaving it with 582 bytes.

22-12-98    Tuesday
        I clean the code a little, eliminate all self-modifying parts and
  optimize a bit. As DEPPTINY v0.3 can't fit a diskette sector, I make
  DEPPTINY v0.2, and it's 439 bytes long (the old 382 bytes long DEPPTINY
  was still first version, with 64K infile limit).

23-12-98    Wednesday >
        Fixed one small bug. I'll send him new versions of DEPPACK v0.3
  and DEPPTINY v0.2 and v0.3

 7-01-99    Thursday
        Back to classes, computer rooms closed due to remote-boot server
  is down. I wanna check mail!

12-01-99  > Tuesday
        I see a quite old message, he has managed to cut the size of
  DEPPTINY v0.3 down to 550 bytes. Maybe it's possible to fit under 513
  bytes, but still I doubt it. He also sent me a pre-release BETA of
  aPACK.

13-01-99    Wednesday >
        As I found a bug on tested aPACK, I wrote Jibz about it and telling
  him I'm about to start my exams, so he shouldn't wait for my new DEPPTINY
  version to release aPLib.

15-01-99  > Friday >
        aPLib 0.20b has finally been released. Jibz has adapted my code to
  his syntax, and re-added the C conexion parts. No problem about it, after
  all, aPLib is HIS product, and this way the format is more regular.
  There's also a TASM version which work with BC. Examples still almost
  unchanged, he just updated the date from 1998 to 1998-99
        But to my nasty surprise, the adapted routines are outdated, and my
  last core optimizations (3 bytes) were not added. I add them and also short
  some jumps in TASM version. I send corrections to him, but I'm not sure if
  he'll update it in v0.20b or in next release...

17-01-99    Sunday
        Can't resist the temptation. Take a look on DEPPTINY. Kill 9 bytes.
  Now it's 541.

18-01-99    Monday >
        Send new DEPPTINY to Jibz.

19-01-99  > Tuesday
        AAAAARRGH! He did it! Managed to reduce 29 bytes, leaving DEPPTINY
  with 512. Hurra! The only-one diskette sector size has been reached! This
  guy is really incredible... And core size has been reduced 5 more bytes...

27-01-99    Wednesday
        Oooops! DEPPTINY is buggy... It seems that last optimizations where
  a little bit too agressive. Urg! it's my fault!!!. It was my last 9 bytes
  killed!. Can't believe it and can't understand why it fails. Let's debug
  it... Ok I found my bug. Hop! Fixed. No penalty bytes. It's still 512.

28-01-99    Thursday >
        Send bugfixed DEPPTINY to Joergen.

15-02-99    Monday
        It has taken me three months to realize that DEPPACK and DEPPTINY
  were supporting drives and paths from the begining, despite what DEPPACK
  says in the usage message. How could I be SO stupid.

23-02-99    Tuesday
        Started porting last DEPPTINY optimizations to DEPPACK. It's getting
  harder than I thought. Killed 1 byte on DEPPTINY > 511.

24-02-99    Wednesday >
        Send the 511 one... Instead of looking to all optimizations and put
  and adapt the ones I can to DEPPACK, I've grown a new DEPPACK from last
  DEPPTINY, adding the error messages, but it can't handle "bad infile"
  detection as it was done with previous DEPPACK. It fails on the same way
  of DEPPTINY, and I'm not sure why DEPPTINY fails anyway... It's driving
  me insane!!!

25-02-99    Thursday >
        Send the new non perfect DEPPACK to Jibz. Let's see if he can find
  something about the mysterious bug.

 1-03-99    Monday
        Kill another byte from DEPPTINY > 510. Gonna test it. Arg! Another
  pretty bug! Let's see... DEPPACK works right... 512-DEPPTINY works right
  511-DEPPTINY fails... Strange. Oh, now I've seen it... Bugfixed. Ported
  the 5 bytes core optimizations to DEPACK16 routines, and cleaned 3 bytes
  from C connection part from them.

 3-03-99    Wednesday >
        Send the bugfixed 510 DEPPTINY.