Re: Ellipse() on XP

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

See below...
On Wed, 15 Oct 2008 22:18:26 -0700, Norman Bullen <norm@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

(Top posting because that's the way this thread seems to be going...)

Most of the things that you list do not make PROGRAMMING more difficult.

Asynchronous I/O is difficult in and of itself. It the "OS" doesn't
offer it, you don't have to cope with that difficulty.
****
No it isn't hard at all. I do it all the time. But when it was appropriate, I couldn't do
it, because I had to also run on Win9x, which didn't have it, so I had to create
convoluted solutions that achieved the same goal on a system that did not support, it, and
*that* made programming more difficult.

Also, I/O Completion Ports make really great interthread queues, and not having them made
threading more complex when I needed interthread queues on Win9x.
****

No security doesn't make programming more difficult; it just causes the
"OS" to be, well, insecure.
****
And if I *have* to deal with security, then I have to deal with its non-implementation,
and the dealing with the two platforms DOES make programming more difficult. This meant
that I had to handle all failures and check for non-implementation errors, and then work
around what was going on; I had to disable menus and dialog options rather than give error
messages when the APIs failed. I had to deal with what happened when the files were moved
from Win9x to Windows and then had the wrong protection (I don't do ACLs; someone else
wrote the code, but I had to cope with the failures of the code and modify their code to
work on both platforms). This certainly made programming more difficult.
****

Ability to issue privileged instruction? If you need a capability
offered by a privileged instruction, the ability to use it may make it
easier to write your program. That doesn't mean it's good for the "OS".
***
The number of people who now complain, "My program used to work on Win9x but I keep
getting this illegal instruction trap when I run it on (any version of real Windows)" is
far too high. My problem is that these programs land on my desk, and the fact that they
wrote a kludge that wasn't even functional makes my programming task much more difficult
as I have to do what they should have done in the first place. It doesn't make it easier
to write *my* program; the usage of privileged instructions ("because we could") makes my
job more difficult because I have to rip all that crap out and replace it with something
that makes sense. And, I should add, the structure of their program suffers greatly. I
once got a program that came in four giant files, and the low-level device code with IN
and OUT instructions, and the menuing system and window management code, all lived in the
same source module! I spent months reorganizing the code so it was understandable and
maintainable, and didn't require privileged instructions to function. That certainly made
*my* programming task more difficult. (You missed my point: I was saying that ALLOWING
privileged instructions was a fundamental design error in Win9x!)
****

FAT file systems may not be very stable, efficient, or extendable but I
can't see how they make programming more difficult.
****
Because with FAT files we could have file damage on a crash which cannot occur in NTFS.
And I had to write code to detect that damage and deal with it. I don't have to write
this kind of code in NTFS. It is not easy code to write, and was very data-specific. I
was writing a program that processed the data another program had recorded, and users
running on Win9x were reporting all kinds of data corruption; we never got such reports
from NT users. I had to read through megabytes of data files before we discovered that
(a) the data was bad and (b) in all cases, there was a Win9x crash involved while the data
was being recorded. We were able to reproduce this easily simply by hitting the reset
button on a Win9x box. I also spent several days crashing an NT box at the customer site
trying to get data to be corrupted, but we never had any problems. I can't explain all
the details, particularly after all this time (2001-2002 timeframe) but it was not a
simple append-text-lines application, lots of random access. This was far worse than
transaction failure; we found actual garbage in the Win9x files.

I was also tasked with trying to fix the Win9x recording program to see if we could avoid
the failures. Trying to invent a reliable file system on top of an unreliable file system
is tricky, and we were never successful. They finally decided they would have been better
off sending a small NT box to their customers instead of all the work I went through to
create meaningful reports when the data was trashed.
****

I think I'll agree with you regarding the 16-bit GDI, however. That
forces you to program around "OS" constraints.
****
I delivered a really fine piece of graphics code that worked perfectly on NT4. It
wouldn't run on Win9x, but that wasn't in the contract, so I hadn't worried about it. It
took far too long to replace trivial code with complex code.

In another case, I was using transformation matrices. These were so fundamental to the
graphics algorithms that we saw no way to reimplement them for Win9x, and I ended up
writing graphic transformations on my own. Again, a program intended for Windows 2000
that "suddenly" had to run on Win9x (the entire shop was Win2K, but their field people
were still running Win9x laptops, which apparently nobody had thought about in the
original specs).

In another case, I'd written a printer port monitor and printer language monitor that
worked perfectly on NT4 and 2000, but failed completely on Win9x, because Win9x only
implemented a subset of the capability that the solution depended on. I had to explain to
the client that what they wanted could not be done on Win9x. It wasn't supported. There
was no workaround in this case. This made the client very unhappy, but I had fulfilled
the requirements they put in their contract. It took me six months to collect on that
invoice, and the threat of legal action. That made more than *programming* difficult, it
made conducting my business difficult.

I am truly happy to see these imitation operating systems finally dead.
joe
****

Norm

Joseph M. Newcomer wrote:

16-bit GDI, 16-bit control limitations, no asynchronous I/O (except serial ports), no I/O
Completion Ports, no security, ability to issue privileged instructions in user space (how
can you even call something like this an "operating system"?), FAT file system [created
problems in maintaining file integrity], I was always suffering from these limitations.
But the 16-bit GDI was the single worst feature.
joe

On Wed, 15 Oct 2008 02:12:19 -0700 (PDT), Richard Russell <news@xxxxxxxxxxxxxxx> wrote:


On Oct 15, 2:15 am, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:

It was possible for developers (and in fact very common in the times
Win9x systems were still widely used) to write Win32 application
that worked on Windows 95, Windows 98, Windows NT 4.0, Windows 2000
and Windows XP....

I did it. It was a real pain. We were always being crippled by the
limitations of MS-DOS.

Please give an example of how "limitations of MS-DOS" made programming
Win9x a pain.

My principal Windows application still supports all versions of
Windows from 95 to Vista (excluding NT prior to 4.0); I can see no
good reason to remove Win9x support anytime soon. At no time have I
found maintaining that support at all onerous.

Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
.

Relevant Pages

  • Re: Ellipse() on XP
    ... No security doesn't make programming more difficult; it just causes the "OS" to be, well, insecure. ... FAT file systems may not be very stable, efficient, or extendable but I can't see how they make programming more difficult. ... Win9x systems were still widely used) to write Win32 application ... and Windows XP.... ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Bedeutung von UNICODE (in der Praxis)
    ... Wenn Du mit Deinem Produkt auch einen internationalen Markt ansprechen willst *musst* Du vollständig Unicode-fähig sein, sonst wirst Du es in "nicht englischen" Regionen sehr schwer haben. ... Unicode Programming in MFC ... Bisher haben viele Firmen es nicht gemacht, weil sie noch Win9x unterstützen mussten. ...
    (microsoft.public.de.vc)
  • Re: OT: The Geek defense
    ... That was not multi-processing kernel code. ... The equivalent to a Linux file system would be to start with a bare disk ... Some have claimed here that programming ability is orthogonal to ... "personality" who makes a good programmer. ...
    (comp.lang.cobol)
  • Re: Multi Threading Options
    ... An idea I tried was to build in an object-based file system back around 1977. ... and had no interest at all in the underlying byte stream sent to a compiler. ... something seriously missing in modern programming environments. ... but in a truly modern programming environment these would ...
    (microsoft.public.vc.mfc)
  • Re: Should COBOL be lockedUP for good?...
    ... You are allowing your emotional attachment to COBOL to blind you here. ... isn't wise to do that with ANY language; it is just computer programming, ... Both Richard and Bill have tried to explain their ... You may think it is fine to use the COBOL file system, ...
    (comp.lang.cobol)