Hi, I've been using pngout for a while and I've found it really useful, but the most recent version of pngout doesn't seem to work on Windows NT (4.0 Workstation). When I try to load it, e.g. from a command window, it does nothing, and just returns to the prompt after a moment.
I have a build from September that works, so I don't particularly mind, but I thought I'd mention it anyway.
Agent ME at
Windows NT has removed total compatibility with 16 bit code. No DOS programs will work on NT. Anyways, all Ken has to do is to port it to a Windows C, right? Or did he program it with one of those obscure programming languages that the company who made it died a long time ago and it never got to making a Windows version?
Anonymous at
Agent ME said
Windows NT has removed total compatibility with 16 bit code. No DOS programs will work on NT. Anyways, all Ken has to do is to port it to a Windows C, right? Or did he program it with one of those obscure programming languages that the company who made it died a long time ago and it never got to making a Windows version?
You mean QBASIC? :roll: It should be in C, Ken has stopped using any other language for a long time :wink:
Anonymous at
Anonymous said
Agent ME said
Windows NT has removed total compatibility with 16 bit code. No DOS programs will work on NT. Anyways, all Ken has to do is to port it to a Windows C, right? Or did he program it with one of those obscure programming languages that the company who made it died a long time ago and it never got to making a Windows version?
You mean QBASIC? :roll: It should be in C, Ken has stopped using any other language for a long time :wink:
This is me again, Guest, lol :lol: ...
speaking of QBASIC, was the Build level editor used in Duke3D, made in it?? Or was it ported to C (i remember reading somewhere it was originaly in QB)?
Awesoken at
counting_pine:
Recently, somebody suggested I use GetLongPathName() to expand filenames. I complied even though I knew the function wasn't supported on Windows 95 or Windows NT. I didn't think anyone was using those operating systems anymore. Apparently, I was wrong. So today, I added some OS detection code so it only uses that function if it's supported. Please let me know if the new PNGOUT.EXE I put on my website works on NT.
Agent ME:
I've been compiling PNGOUT with Microsoft Visual C/C++ 6.0 ever since it's been on my site. It is already a native 32-bit Windows program. Console applications can be native windows programs too! You can always tell if it's a native Windows program by looking for this string in the EXE header: "This program cannot be run in DOS mode."
Guest:
Yes, BUILD and PNGOUT both have roots in QuickBasic. I converted them to C a long time ago. I still use QuickBasic for designing new algorithms because it has a nice debugger. Once I convert the code to C, I usually leave the QB code to rot. Very few of the programs on my website were compiled with QuickBasic.
counting_pine at
Ok, so I'm the only person left in the world who uses NT4.
It's not great, I know. It's lacking a few up-to-date features like power management and USB support, and for some reason I have to manually start my sound card driver each time I start up, but it does have it's good points too.
I like it because it's small, like Win95, and fast enough to run on my P-II 400, and is more compatible with VB4, but doesn't suffer from many of the problems in Win9x, e.g. resource management, and it has NTFS support and a better CLI.
I do have another computer with Win98 and WinXP on, but I tend to use my NT4 computer for programming.
Well, anyway, I've tried the latest PNGOUT.EXE. Sadly, it still doesn't work.
I can run it fine on my other computer, though, so don't worry too much about it. And the September version isn't too obselete yet.
Edited at
Agent ME at
Awesoken said
Agent ME:
I've been compiling PNGOUT with Microsoft Visual C/C++ 6.0 ever since it's been on my site. It is already a native 32-bit Windows program. Console applications can be native windows programs too! You can always tell if it's a native Windows program by looking for this string in the EXE header: "This program cannot be run in DOS mode."
DOS programs can be 32 bit too? Oh yeah, just remembered the setting for making a program for the 8036 in PowerBASIC (DOS)
About that sentence in the header, I remember opening up an EXE with a Hex Editor. I wonder if it's possible to change that string so it displays something else?
JonoF at
Sure, hack at it with a hex editor. I can't fully remember whether the string is null terminated or '$' terminated like DOS often requires, but I think it's '$' terminated. I'd have to look up the interrupt list to be sure. A Windows exe is a DOS stub executable plus the 'PE' executable appended. I recall some stub executables in the Win31 days being clever enough to invoke win.com to run themselves so that you wouldn't have to start Windows yourself and run the program.
Jonathon
ShadowX at
wow, and I thought I was the only one who still used QBasic for testing stuff out. I don't feel like quite as much of loser any more.
Anonymous at
Agent ME said
Awesoken said
Agent ME:
I've been compiling PNGOUT with Microsoft Visual C/C++ 6.0 ever since it's been on my site. It is already a native 32-bit Windows program. Console applications can be native windows programs too! You can always tell if it's a native Windows program by looking for this string in the EXE header: "This program cannot be run in DOS mode."
DOS programs can be 32 bit too? Oh yeah, just remembered the setting for making a program for the 8036 in PowerBASIC (DOS)
I think you misunderstod Ken, just becaues it uses the console (or as you know it as the DOS command window) dos NOT make it a DOS program, PNGOUT is a native Wndows program (it is compiled in the Win32 binary format) and requires Windows to be running to work.
And yes, dos programs can be 32bit too (but this dose not make them a Windows program). Infact most DOS popular games; by use of a DOS extender like DOS4GW, needed to be 32bit to allocate the amount of memory need to run them possible (the max addressable by a 286+ CPUs in real mode (essentially an emulated 8086) is 1MB with out disgusting memory window hacks (like EMS), however about a third of it is required for memory addresses for the BIOS and various adaptor cards leaving you with 640KB).
As for Windows NT not capable to running DOS progams is not true, it always could since the NT3.5 days when win32 was first introduced. It was just that DOS programs were very limited in what they can do, becaues NT dosen't allow direct access to hardware other than the bare nessesities and a bonus of basic VGA. This made alot of DOS programs a pain in the ass to get working, becaues in "real" DOS programs are allowed to basically do whatever they want with whatever they want.
Anonymous at
Anonymous said
Agent ME said
Awesoken said
Agent ME:
I've been compiling PNGOUT with Microsoft Visual C/C++ 6.0 ever since it's been on my site. It is already a native 32-bit Windows program. Console applications can be native windows programs too! You can always tell if it's a native Windows program by looking for this string in the EXE header: "This program cannot be run in DOS mode."
DOS programs can be 32 bit too? Oh yeah, just remembered the setting for making a program for the 8036 in PowerBASIC (DOS)
I think you misunderstod Ken, just becaues it uses the console (or as you know it as the DOS command window) dos NOT make it a DOS program, PNGOUT is a native Wndows program (it is compiled in the Win32 binary format) and requires Windows to be running to work.
And yes, dos programs can be 32bit too (but this dose not make them a Windows program). Infact most DOS popular games; by use of a DOS extender like DOS4GW, needed to be 32bit to allocate the amount of memory need to run them possible (the max addressable by a 286+ CPUs in real mode (essentially an emulated 8086) is 1MB with out disgusting memory window hacks (like EMS), however about a third of it is required for memory addresses for the BIOS and various adaptor cards leaving you with 640KB).
As for Windows NT not capable to running DOS progams is not true, it always could since the NT3.5 days when win32 was first introduced. It was just that DOS programs were very limited in what they can do, becaues NT dosen't allow direct access to hardware other than the bare nessesities and a bonus of basic VGA. This made alot of DOS programs a pain in the ass to get working, becaues in "real" DOS programs are allowed to basically do whatever they want with whatever they want.
umm, just about everyones (including the program's author, Ken) already said exactly what you just said :rolleyes:
kode54 at
Awesoken said
counting_pine:
Recently, somebody suggested I use GetLongPathName() to expand filenames. I complied even though I knew the function wasn't supported on Windows 95 or Windows NT. I didn't think anyone was using those operating systems anymore. Apparently, I was wrong. So today, I added some OS detection code so it only uses that function if it's supported. Please let me know if the new PNGOUT.EXE I put on my website works on NT.
There's a wrapper for that in NewAPIs.h, which should be in the latest Windows Platform SDK. Here is a copy in case you don't have it.
Awesoken at
Thanks for the info, kode54.
I originally added GetLongPathName because somebody mentioned that when you use "for %i in (*.png) do pngout %i" in Win98, the OS was providing PNGOUT with short (8.3) filenames. This is actually a problem with the operating system, not PNGOUT. If you write the long filenames out explicity (not use the 'for' command), it will work fine.
I could patch it with NewAPIs.h, but it really bothers me to put this mess in my code just to fix a silly issue with obsolete operating systems. I have decided to remove GetLongPathName() completely. This will hopefully fix the 95/NT problems. As a bonus, it should bring PNGOUT.EXE back down to 31K. : )
kode54 at
Awesoken said
I originally added GetLongPathName because somebody mentioned that when you use "for %i in (*.png) do pngout %i" in Win98, the OS was providing PNGOUT with short (8.3) filenames. This is actually a problem with the operating system, not PNGOUT. If you write the long filenames out explicity (not use the 'for' command), it will work fine.
Fun times for those who finally make the switch to NT, the first time they use that and realize they need quotes around the filename in case there are any filenames with spaces.
More semi-useful information, heh.
counting_pine at
:)
PNGOut works again in Windows NT - which is cool, although I feel a bit guilty for depriving Windows 98 users of GetLongPathName.
kode54 at
Re: :)
counting_pine said
PNGOut works again in Windows NT - which is cool, although I feel a bit guilty for depriving Windows 98 users of GetLongPathName.
... Oh yes, I forgot that this utility writes the output to a new file. The tools I use (my own resizer/lossless reducer/palette sorter, pngrewrite, OptiPNG, advpng/advdef, and TweakPNG for finishing touches) all work in-place. Although, a friend does include pngout along with all of the above (excluding TweakPNG, which is not an automated tool) and then some crammed into his own brute force repacking script, which I can't seem to find on his site anymore...
KillerQ13 at
pngout on Windows NT
How about using FindFirstFile to get the long file name? If you're feeling adventurous you could use FindNextFile and support wild cards internally.
Awesoken at
How about using FindFirstFile to get the long file name? If you're feeling adventurous you could use FindNextFile and support wild cards internally.
That's a good idea. I could make PNGOUT support wildcards for filenames internally (example: pngout *.png). This would make the 'for' command no longer necessary. I'm sure I'll get around to doing this eventually... it's just not a high priority for me right now. Until then, another solution would be to replace the 'for' command with some 3rd-party tool that handles filenames correctly.
BTW, if you're looking for a short & simple wild card matching algorithm, you can take the wildmatch() function I wrote for KPLIB.C : ) You can find a copy of KPLIB.C in the Voxlap Library or in JFBuild.
KillerQ13 at
Awesoken said
BTW, if you're looking for a short & simple wild card matching algorithm, you can take the wildmatch() function I wrote for KPLIB.C
No thanks. I'm a lowly Visual Basic 6 programmer...albeit a very good one (minus databasing). I've got the Like operator at my disposal but if I ever get ahold of VC++ 6 and start learning it, I'll keep that in mind. Hopefully that'll be soon since I really want to mess around with the Voxlap library and have a fancy GUI editor to help me.
Anonymous at
KillerQ13 said
Awesoken said
BTW, if you're looking for a short & simple wild card matching algorithm, you can take the wildmatch() function I wrote for KPLIB.C
No thanks. I'm a lowly Visual Basic 6 programmer...albeit a very good one (minus databasing). I've got the Like operator at my disposal but if I ever get ahold of VC++ 6 and start learning it, I'll keep that in mind. Hopefully that'll be soon since I really want to mess around with the Voxlap library and have a fancy GUI editor to help me.
VB6's GUI editor is fancier than VC++6's (shudders)...