DOS ain't dead

Hi

I just uploaded a port of GIFSICLE to DOS (32-bit DOS application) (and a Win32 port also) :

http://freefile.kristopherw.us/uploads/temp/ (DOS + Win32 + SRC's all in)

My version is 1.50K and is based on Eddies's 1.50 sources.

GIFSICLE is a commandline tool for creating, decomposing and editing of animated GIF's originating from Linux.

What's new:

- Frame decomposition really works
- Added a Win32 port also. Why the hell ? Preventive theft of possible "reasons" to run the DOS port on non-DOS systems
- Some bugs added (sorry my port is a bit experimental and immature)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

See shot:

GBTTRR - rr's port
GIFD - my DOS port
GIFW - my Win32 port
OS = EDR-DOS (no space in the shot for "VER" )

rr wrote # :

> Go play with some other childs.

Thanks for the generous offer but I prefer to leave the "childs" alone in their Vista box

> No "RTFM", but "it's all in the docs".

No system requirements. Too much Linux stuff. Docs for inexistent "GIFVIEW".

> I'm not sure, what your problem is, so just report your bug

OK. But to protect myself from unreasonably proud "declined" I released my port first.

> and we'll see, if it's for real.

It is. It doesn't work in DOS, at least the frame decomposition (see shot). It's about filenaming in DOS and filenaming in DGJPP packages ... most likely you won't consider it as bug. You ported it into Vista NTVDM and I ported it to DOS.

My DOS port in 1.33 times less bloated. Your port requires a DPMI host but none is built-in - probably one is supposed to "already have one" - the D policy is well known and impossible to fix

rugxulo wrote:

> It makes animated .GIFs, right?

YES. And more.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Features:

- Decompose ani GIF into GIF frames (diff only)
- Create ani GIF from GIF frames
- Optimize ani GIF (does not always work ??)
- Deoptimize ani GIF (needed before extracting full frames)
- ZOOM ani GIF (nearest neighbor ?)
- Add and delete frames (untested)

Bugs:

- Some background / trans trouble - random ? Both rr's and my port , try with the "R.I.P." GIF I uploaded
- Decomposing doesn't work at all (rr's only)
- Wildcards don't work, must specify all frames (my only, GCC vs non-GCC problem)
- Floyd and Pipe/Pope coloring (needed at all ? for what ?) is crapped in my port

Lacks:

- BMP input and output
- List file with input frames
- Decompose into full frames directly without need to deoptimize first

Viewing ani GIF's in DOS:

- LXPIC (some trans problems ???)
- DISPLAY

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> OS = EDR-DOS (no space in the shot for "VER" )

This is why I usually put the OS name in the prompt, e.g. "prompt [ FreeDOS ] $D$g". You can also use extended VGA textmode (beyond 80x50) via Japheth's SETMxx tools.

> No system requirements. Too much Linux stuff. Docs for inexistent "GIFVIEW".

Yeah, GIFVIEW requires X11 (although we have DOS viewers, so this is moot).

> Viewing ani GIF's in DOS:
>
> - LXPIC (some trans problems ???)
> - DISPLAY

There's also XPL0's SEE w/ src (and probably various others that Steve will probably point out, heh).

> Your port requires a DPMI host but none is built-in - probably one is
> supposed to "already have one" - the D policy is well known and
> impossible to fix

Well, I've started reading in a few places that "FreeDOS comes with DPMI server by default". And to be honest, CWSDPMI is fairly ubiquitous.

> > Viewing ani GIF's in DOS:
> >
> > - LXPIC (some trans problems ???)
> > - DISPLAY
>
> There's also XPL0's
> SEE w/ src (and
> probably various others that Steve will probably point out, heh).

PictView is a nice multi-format viewer/converter.
Home page:
http://www.pictview.com/ (English)
or
http://www.pictview.com/cz/index.htm (Czech)

> > Go play with some other childs.
>
> Thanks for the generous offer but I prefer to leave the "childs" alone in
> their Vista box

Just curious: shouldn't it be "children" instead of "childs". Or is the first totally outdated nowadays?

> OK. But to protect myself from unreasonably proud
> "declined" I released my port first.

Very wise!

> It is. It doesn't work in DOS, at least the frame decomposition (see
> shot). It's about filenaming in DOS and filenaming in DGJPP packages ...
> most likely you won't consider it as bug. You ported it into Vista NTVDM
> and I ported it to DOS.
>
> My DOS port in 1.33 times less bloated. Your port requires a DPMI host
> but none is built-in - probably one is supposed to "already have one" - the
> D policy is well known and impossible to fix

Ok, but that's a minor issue.

In the docs there is mentioned it runs with FreeDOS 1.1. What's the problem with FD 1.0?

Anyways, I tried your port (both DOS and Win32) and it failed with the very first step.

GIFx xxx.gif >yyy.gif

I'd expect that without any options the output GIF is somewhat equal to the input one - and this is indeed true for Robert's port -, but with GIFD/GIFW I'm getting garbage as output.

The GIF I used was a 500x600 picture.

---
MS-DOS forever!

> Anyways, I tried your port (both DOS and Win32) and it failed with the
> very first step.
>
> GIFx xxx.gif >yyy.gif
>
> I'd expect that without any options the output GIF is somewhat equal to
> the input one - and this is indeed true for Robert's port -, but with
> GIFD/GIFW I'm getting garbage as output.

I noticed that too and I have a clue of what's the cause, but DOS386's port is really a very badly designed hack, so I won't help. He has moved a lot of files around, made source code changes w/o #ifdefs, there's no Makefile (or build.bat), no GNU Diff file, ... Of course, I plan to fix my build and release clean archives.

> The GIF I used was a 500x600 picture.

Doesn't matter.

---
Forum admin

> I noticed that too and I have a clue of what's the cause, but DOS386's
> port is really a very badly designed hack, so I won't help.

Sounds not very reasonable to me. Do you only consider to help if things are already perfect?

> He has moved a
> lot of files around, made source code changes w/o #ifdefs, there's
> no Makefile (or build.bat), no GNU Diff file, ...

Yes, but his port is made with nice, good and exciting OW, while yours uses bloated, boring and buggy DGPJJ.

---
MS-DOS forever!

> > I noticed that too and I have a clue of what's the cause, but DOS386's
> > port is really a very badly designed hack, so I won't help.
>
> Sounds not very reasonable to me. Do you only consider to help if things
> are already perfect?

No, but I don't want to waste my time digging a rubbish dump, if I already have a much cleaner way here.

> Yes, but his port is made with nice, good and exciting OW, while yours
> uses bloated, boring and buggy DGPJJ.

That's very reasonable, of course. So just ignore my port.

---
Forum admin

> That's very reasonable, of course. So just ignore my port.

of course I will. However, you're off-topic, this thread is about DOS386's port.

---
MS-DOS forever!

> Yes, but his port is made with nice, good and exciting OW, while yours
> uses bloated, boring and buggy DGPJJ.

So how exactly do you get OpenWatcom to expand wildcards (a la DJGPP globbing) into separate members in argv[]? wildargv.c? (Last I tried, it didn't work for me, but I probably did it incorrectly.)

> So how exactly do you get OpenWatcom to expand wildcards (a la DJGPP
> globbing) into separate members in argv[]? wildargv.c? (Last I tried, it
> didn't work for me, but I probably did it incorrectly.)

That's a good question. There's a file WILDARGV.OBJ, which must be specified in the link step to replace the standard argv handling. I didn't try it yet, but JWasm could also benefit from this knowledge.

---
MS-DOS forever!

> > So how exactly do you get OpenWatcom to expand wildcards (a la DJGPP
> > globbing) into separate members in argv[]? wildargv.c? (Last I tried,
> it
> > didn't work for me, but I probably did it incorrectly.)
>
> That's a good question. There's a file WILDARGV.OBJ, which must be
> specified in the link step to replace the standard argv handling. I didn't
> try it yet, but JWasm could also benefit from this knowledge.

Whew, a really easy answer, luckily! (I was used to Turbo C and CC386 only needing WILDARGV.C by itself, hence the many errors when trying to compile without INITARG.H being found). You need both %WATCOM%\SRC\STARTUP\wildargv.c and initarg.h (I just copied 'em to the current dir). Then, you'll see it works:

// TEST.C
#include <stdio.h>

int main( int argc, char* argv[] )
{
  int i;

  if (argc > 1) for (i=1; i < argc; i++) printf("%s,",argv[i]);

  return 0;
}

wcl386 -q test
test *.zip (prints "*.zip,")

... or ...

wcl386 -q test wildargv
test *.zip (prints a list of .ZIPs in the current dir)

P.S. You can get WILDARGV.C and INITARG.H in MISC_SRC.ZIP (109k) if you don't already have it. However, it's packed in Deflate64, so use Info-Zip's UNZIP (or p7zip, 7za + HX, etc) if necessary.

> Whew, a really easy answer, luckily! (I was used to Turbo C and CC386 only
> needing WILDARGV.C by itself, hence the many errors when trying to compile
> without INITARG.H being found). You need both
> %WATCOM%\SRC\STARTUP\wildargv.c and initarg.h (I just copied 'em to the
> current dir). Then, you'll see it works:

Thanks! However, it doesn't work for JWasm, because some "cleverle" has introduced direct access to the cmdline in Wasm, without using argc/argv.

---
MS-DOS forever!

> > Whew, a really easy answer, luckily! (I was used to Turbo C and CC386
> only
> > needing WILDARGV.C by itself, hence the many errors when trying to
> compile
> > without INITARG.H being found). You need both
> > %WATCOM%\SRC\STARTUP\wildargv.c and initarg.h (I just copied 'em to the
> > current dir). Then, you'll see it works:
>
> Thanks! However, it doesn't work for JWasm, because some "cleverle" has
> introduced direct access to the cmdline in Wasm, without using argc/argv.

argc/argv is a (C) language concept. There is no universal argc/argv (even under *nix)

> argc/argv is a (C) language concept. There is no universal argc/argv (even
> under *nix)

Thanks for confirming and additional information! (JWasm IS a C program).

---
MS-DOS forever!

> (JWasm IS a C program).

Don't worry! That is fixable

> docs there is mentioned it runs with FreeDOS 1.1. What's the problem with FD 1.0?

No big problem. Qualifies as "compatible"

> tried your port (both DOS and Win32) and it failed with the very first step.
> GIFx xxx.gif >yyy.gif

GIFD XXX.GIF -o YYY.GIF

> I'd expect that without any options the output GIF is somewhat equal to
> the input one

Very useful

> and this is indeed true for Robert's port -, but with GIFD/GIFW I'm getting garbage

The ">" is a bad hack and was supposed to get disabled in my port ... that it isn't has to be considered as bug of course, but it doesn't prevent you from using the thing, just use intentionally the correct syntax instead of intentionally the wrong one.

rr wrote:

> I noticed that too and I have a clue of what's the cause

Me too.

> but DOS386's port is really a very badly designed hack

At least, my docs do warn from this fact.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> just use intentionally the correct syntax instead of intentionally the wrong one.

Obviously you have no idea how stupid users usually act. You cannot see into my brain, so you have no evidence for your claim that it was "intentionally" and therefore it's "unwise" to suggest that.

---
MS-DOS forever!