Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page

DOS386

09.05.2008, 06:57

GIFSICLE 1.50K uploaded DOS (+Win32) port really works now (Announce)

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 :clap:
- Added a Win32 port also. Why the hell ? Preventive theft of possible "reasons" to run the DOS port on non-DOS systems :-P
- Some bugs added (sorry :crying: 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 ***

DOS386

09.05.2008, 07:07

@ DOS386

GIFSICLE 1.50K uploaded DOS (+Win32) port really works now

See shot: [image]

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. :-P

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 :lol3:

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 ***

DOS386

09.05.2008, 08:02

@ DOS386

GIFSICLE 1.50K uploaded DOS (+Win32) port really works now

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 :hungry:
- 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 ***

Rugxulo

Usono,
09.05.2008, 14:57

@ DOS386

GIFSICLE 1.50K

> 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 :lol3:

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.

Steve US, 09.05.2008, 17:02 @ Rugxulo	GIFSICLE 1.50K Post reply
	> > 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)

Japheth

Germany (South),
13.05.2008, 15:12

@ DOS386

test report

> > 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. :-P
>
> 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 :lol3:

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!

rr

Berlin, Germany,
13.05.2008, 17:00

@ Japheth

test report

> 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

Japheth

Germany (South),
13.05.2008, 18:23

@ rr

test report

> 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!

rr

Berlin, Germany,
13.05.2008, 21:38

@ Japheth

test report

> > 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

Japheth

Germany (South),
13.05.2008, 21:55

@ rr

test report

> 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!

Rugxulo Usono, 13.05.2008, 22:25 @ Japheth	test report Post reply
	> 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.)

Japheth

Germany (South),
13.05.2008, 23:06

@ Rugxulo

test report

> 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!

Rugxulo

Usono,
14.05.2008, 00:39

@ Japheth

test report

> > 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.

Japheth

Germany (South),
14.05.2008, 08:34

@ Rugxulo

test report

> 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!

marcov

14.05.2008, 10:04

@ Japheth

test report

> > 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)

Japheth

Germany (South),
14.05.2008, 11:46

@ marcov

test report

> 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!

marcov 14.05.2008, 11:56 @ Japheth	test report Post reply
	> (JWasm IS a C program). Don't worry! That is fixable

DOS386

31.05.2008, 01:56

@ Japheth

BUG

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

No big problem. Qualifies as "compatible" :clap:

> 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 ***

Japheth

Germany (South),
31.05.2008, 07:49

@ DOS386

BUG

> 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!

Back to index page

22632 Postings in 2109 Threads, 402 registered users, 424 users online (0 registered, 424 guests)
DOS ain't dead | Admin contact

powered by my little forum