"Paul" wrote

| But surely you look for a libpng,
| before writing your own ?
|
| I'm not much of a programmer, but if a library
| is available, I'll use it.

I'm the opposite. I use conveniences when I can,
where it doesn't matter. I love VB6 for that. It's
very simple to get basic GUI controls with little
work. But I like the efficiency and portability of
avoiding wrappers. So for actual operations in the
software I try to use straight code or Win32 API.

Before GDI+ I used to use a small JPG library
written in Delphi, and at that time PNG was virtually
unknown. Now with GDI+ I can call that to handle
JPG saving. And PNG still isn't very popular. I only
wrote the code because I wanted it for my Explorer
Bar. I actually adapted someone else's unfinished code.

Awhile back I was talking to a friend who works in
Java and said I liked to use direct Win32 API whenever
possible. He said, "Oh, yeah, the old Win32". Most
people think of it that way now. They've got .Net or
Java wrapping Win32. Often there are even intermediate
DLLs to simplify things. They don't understand that
they're still using Win32 API. They think they have
"a more modern tool".

I think of it like cooking. There are numerous levels
of brass tacks. If you want a pasta dinner you can
order take-out and have it delivered. Or you
can go pick it up. Or you can zap a frozen dinner. Or
you can boil spaghetti and dump some bottled Ragu
on top. Or you can add some oregano and onions to the
Ragu for "customization". Or you can make your own
sauce. You can even make your own pasta. And you
could grow your own tomatoes. Perhaps even grow and
grind your own wheat. I'm not a fanatic. I don't work in
assembly. But I like to do my own cooking. It's more
efficient, more flexible, and less costly. So I make my own
sauce. And my software can run on virtually any Windows
machine in use without needing support files. I've never
even written a program much over 1 MB.

Most software used to be like that. MS Office 95 installed
from a pile of floppies. My PSP16 is probably about 5 times
the size of PSP5 and labors to start up. It's got almost
as much Python crap as the entire PSP5! Yet it only has
slightly more functionality than PSP5. And the GUI is worse.
So I only use 16 rarely.

People used to make fun of the RAD simplicity of VB,
yet now the former hardcore C++ people are using the
C# or VB.Net wrapper -- a bloated, "for dummies" OO
system.

I've written my own code for many things. Winsock,
http, smtp, cabinet.dll, graphics operations, NT permissions,
color syntax highlighting in a RichEdit, typelib parsing,
etc. Partly I like the challenge. But I also like to make it
clean and know the code. And it's much more efficient
that way. .Net software has to load gobs of DLLs just
to start, then all calls go through a chain of wrappers.
I'm mostly just calling the Win32 API directly, or using
straight code operations, except for most GUI elements.

It allows me to write exactly what I need and it's usually
better than what's available. For instance, at one point
I wanted a quick color syntax highlighter in VBScript, for
an HTA, so I could paste obfuscated webpage script to
read it more easily. I found the "open source" jsbeautifier.
It was crap. I wrote a much better version in a few days.
But everyone else was using jsbeautifier because it was
the OSS standard.

I suppose most things are like that. More and more
specialization. Fewer and fewer people writing their own
code, or doing their own oil changes, or cooking their
own dinner... The other day I was at Home Depot looking
for laminate (formica, etc) snips and discovered they no
longer sell laminate, trimmers, glue, or snips. Laminate
is now a specialty. The store for contractors and handymen
is turning into an outlet to buy take-out spaghetti dinners.

Though I can't really say I write all the code. I usually
find sample code to get me started, for most things, as
with the PNG parser.

I also wrote VB code for turbojeg.dll, an OSS DLL.
I wanted to be able to display JPG tumbnails quickly.
The quickest way is to just extract it from the file.
But not all JPGs have an embedded thumbnail. And some
can be very big. After a lot of research I found that
turbojpeg seemed to offer the fastest possible JPG
parsing to get a thumbnail out of a giant image. It's
very fast at making reduced size images of high quality.
But for basic operations GDI+ is fine.

| The problem now, is a shortage of tools for images
| with over 4 billion pixels :-) (Yeah, I only have
| one file like that. It's 10GB or so. I'd show it
| to you, but... the image hosting sites would not
| like that.)
|
I hope that's a picture of your adorable baby. I'd
rather think of you as a sentimentalist than as being
entirely out to lunch.