As Steve Balmer correctly stated, while making his monkey dance, it is
applications and hence programmers that make a platform. The fact though is
that if you want to do professional programming, then Linux is the platform
for you. I know that this statement will get the heckels up on a lot of
trolls in C.O.L.A, but I have a recent experience that proves this.

I am currently working for a Windows only house producing a system that
receives and transmits around 1000 telegrams per second in each direction
on a UDP socket, translates them into a different format and creates a log
entry for each telegram so that it can be processed off-line and receives
and sends the data to another application over a TCP/IP socket. The program
is multi-threaded and is written in C++. This is perhaps not the ideal
language, but it was a requirement that came down from on high, when the
original project was initiated.

I had been in charge of the original production of this code, but a bunch of
monkeys had been working on the code for a couple years and had made a
complete mess of the program.

I have a couple of firm rules:
1) All code is to be generic. Code that works on only one platform does not
belong to you, it belongs to the platform.

2) All external interfaces have only one point of access. This includes API
calls to the OS. I have an abstraction layer that provides an interface
based on functional objects. It also provides a set of low level string
handling functions and a set of standard objects for things like thread
creation, synchronisation and inter-thread / inter-process communications.

The first thing I did when taking on the project is ran a number of
different compilers over the code to find where non-standards coding had
been used. I find that GCC 4.x is the most picky about coding errors.

Microsoft compilers are very willing to accept coding errors and in many
cases do a reasonable job of interpreting the code. The problem is that all
the compiler can do with non-standard code is attempt to guess what the
programmer had in mind. The compiler may or may not get it correct.

This analysis together with a restructuring of the poorly designed sections
fixed a lot of the problems in the code. It was then possible to put the
new functionality into the project.

Around a month ago we finished programming and started putting the system
through its paces. We found that there was a bug in the code that would
cause cataclysmic failure of the program. At least with Windows 2003, the
OS did not crash with application. We were not able to find the cause of
the problem. The company, being an all Microsoft house has hundreds of
thousands of dollars worth of tools like Rational Quantify/Purify and
Bounds checker. It is really easy to spend a fortune on Windows programming
tools, because they are so expensive. e.g. US$5000 for a single
Quantify/Purify license.

We tried to find the cause of the failure with the large set of tools
available to us. The problem always came back to the same thing. The
program was gone and there was no way to know what state it was in when it
died. Even running the program within Visual studio would cause Visual
Studio to fail.

I finally gave up on the Windows tools and I ported the abstraction layer to
Linux. I started by trying to port the solaris version of the abstraction
layer, but then discovered that there is a really good site at
www-128.ibm.com/developerworks that gives some easy steps to port Windows
code to Linux. After a weekend of porting the abstraction library, it was a
trivial task to compile the application and get it running under Linux. The
only real catch in the whole process was with select. The rfds to be passed
in is the the highest socket ID plus 1. That is a little different to the
unix versions I've used, where the number of entries in the fd_set is
passed in and very different to Windows, where -1 is always passed in.

The next step was to put a second partition onto the test machine. That is
an easy task these days. We compiled the application with -g and started
running it under gdb. GDB was very quick at picking up a few errors, which
were able to fix up. We then left the application running over night. An
interesting thing that we noted, was that we needed to send 50% more
telegrams per second to give the same percentage CPU usage loading on the
application. The application simply runs much faster under Linux. A later
test of the application compiled with the -O3 gave another 10% improvement
in performance.

By the morning, we had a nice core dump and it was then trivial to find the
offending code. I have read the Wintrolls write that it is possible to have
a core dump produced by Windows, but I haven't been able to find how to do
it. Maybe one of the trolls will actually explain how this is done. I
suspect that this is just hot air.

Once we had the main problem cured, we then linked in electric fence and
this found a few errors that Purify had not found. Most recently we have
been running the application in valgrind and it has found even more errors.

Pretty well every Linux distro gives you all the tools required to develop
professional programs. The equivalent tools for Windows would set you back
thousands of dollars and they don't seem to work as well as the free tools
you get with Linux.

If you want to produce professional code, Linux is the way to go. Now all
that has to happen is the PHB's have to realize that the Microsoft FUD is
pure lies and we will see a real sea change in the computer industry.

Ian

In article <104bb$44afb8d7$544a537b$32577@news.hispeed.ch>, Ian Hilliard
wrote:
> I am currently working for a Windows only house producing a system that
> receives and transmits around 1000 telegrams per second in each direction
> on a UDP socket, translates them into a different format and creates a log
> entry for each telegram so that it can be processed off-line and receives
> and sends the data to another application over a TCP/IP socket. The
> program is multi-threaded and is written in C++. This is perhaps not the
> ideal language, but it was a requirement that came down from on high, when
> the original project was initiated.
....
> I have a couple of firm rules: 1) All code is to be generic. Code that
> works on only one platform does not belong to you, it belongs to the
> platform.

If you limit yourself to generic code that works on all platforms, you put
quite a constraint on performance, since you will be limited to select() for
managing sockets.  That has scalability problems.  All major platforms have
alternatives to select designed to get around this, but then the code isn't
generic.  E.g., realtime signals on 2.4 Linux kernels, epoll on 2.6 kernels,
kqueue on *BSD, I-forget-what-it-is-called on Windows.

If you want to allow for maximum scalability, you are probably better off
defining a generic interface to the network layer, and then allowing
non-generic implementations of that interface.

It's a little dated now, but this article is very informative:

    <http://www.kegel.com/c10k.html>

-- 
--Tim Smith

"Ian Hilliard" <nospam@hilliardtech.com> wrote in message 
news:104bb$44afb8d7$544a537b$32577@news.hispeed.ch...
>
Why don't you get your employer to pay a little bit to send you to a 
debug techniques class, Ian, then you wouldn't look like such an idiot. 

__/ [ Ian Hilliard ] on Saturday 08 July 2006 14:53 \__

> As Steve Balmer correctly stated, while making his monkey dance, it is
> applications and hence programmers that make a platform. The fact though is
> that if you want to do professional programming, then Linux is the platform
> for you. I know that this statement will get the heckels up on a lot of
> trolls in C.O.L.A, but I have a recent experience that proves this.


Actually, the infamous Monkey Dance scene (quite a display of insanity!)
involves just yelping and some loud cheers of "yeah". The scene you are
thinking of is sweaty Ballmer saying "developers" 14 times. See the
following:

http://www.ntk.net/ballmer/mirrors.html

Speaking of loud cheering (and even screaming)...

,----[ Quote ]
| Public Persona
| 
| Ballmer's tendency to loudly and enthusiastically express himself is
| well known. A famous 1991 incident left his vocal cords requiring
| repairative surgery after he screamed "Windows, Windows, Windows"
| continuously during a meeting in Japan[1]. With the advent of internet
| video, such incidents have become increasingly infamous.
`----

                        http://en.wikipedia.org/wiki/Ballmer



> I am currently working for a Windows only house producing a system that
> receives and transmits around 1000 telegrams per second in each direction
> on a UDP socket, translates them into a different format and creates a log
> entry for each telegram so that it can be processed off-line and receives
> and sends the data to another application over a TCP/IP socket. The program
> is multi-threaded and is written in C++. This is perhaps not the ideal
> language, but it was a requirement that came down from on high, when the
> original project was initiated.


This sounds like an intersting project. Judging from what I read, home
automation and DIY robotics is better managed by GNU/Linux.


> I had been in charge of the original production of this code, but a bunch
> of monkeys had been working on the code for a couple years and had made a
> complete mess of the program.


Never trust a code monkey in a cubicle. Uninspired programmers produce buggy
and undependable code. Compare with Google's lenient working conditions, for
instance.


> I have a couple of firm rules:
> 1) All code is to be generic. Code that works on only one platform does not
> belong to you, it belongs to the platform.
> 
> 2) All external interfaces have only one point of access. This includes API
> calls to the OS. I have an abstraction layer that provides an interface
> based on functional objects. It also provides a set of low level string
> handling functions and a set of standard objects for things like thread
> creation, synchronisation and inter-thread / inter-process communications.
> 
> The first thing I did when taking on the project is ran a number of
> different compilers over the code to find where non-standards coding had
> been used. I find that GCC 4.x is the most picky about coding errors.


"Errors" or "warning"? Verbose compilers can make miserable programmers,
especially if they refuse to compile. Testing software can compensate for an
overly permissive compiler.


> Microsoft compilers are very willing to accept coding errors and in many
> cases do a reasonable job of interpreting the code. The problem is that all
> the compiler can do with non-standard code is attempt to guess what the
> programmer had in mind. The compiler may or may not get it correct.


Perhaps it's Microsoft's way of encouraging you to use the Visual Studio
debugger, which I hear is rather valuable. Or maybe they want you to but
some extra testing software that is pricey. It's a bit like spam filtering
(or lack thereof )in Outlook Express and Outlook (same rubbish; one work
less).


> This analysis together with a restructuring of the poorly designed sections
> fixed a lot of the problems in the code. It was then possible to put the
> new functionality into the project.
> 
> Around a month ago we finished programming and started putting the system
> through its paces. We found that there was a bug in the code that would
> cause cataclysmic failure of the program. At least with Windows 2003, the
> OS did not crash with application. We were not able to find the cause of
> the problem. The company, being an all Microsoft house has hundreds of
> thousands of dollars worth of tools like Rational Quantify/Purify and
> Bounds checker. It is really easy to spend a fortune on Windows programming
> tools, because they are so expensive. e.g. US$5000 for a single
> Quantify/Purify license.
> 
> We tried to find the cause of the failure with the large set of tools
> available to us. The problem always came back to the same thing. The
> program was gone and there was no way to know what state it was in when it
> died. Even running the program within Visual studio would cause Visual
> Studio to fail.
> 
> I finally gave up on the Windows tools and I ported the abstraction layer
> to Linux. I started by trying to port the solaris version of the
> abstraction layer, but then discovered that there is a really good site at
> www-128.ibm.com/developerworks that gives some easy steps to port Windows
> code to Linux. After a weekend of porting the abstraction library, it was a
> trivial task to compile the application and get it running under Linux. The
> only real catch in the whole process was with select. The rfds to be passed
> in is the the highest socket ID plus 1. That is a little different to the
> unix versions I've used, where the number of entries in the fd_set is
> passed in and very different to Windows, where -1 is always passed in.
> 
> The next step was to put a second partition onto the test machine. That is
> an easy task these days. We compiled the application with -g and started
> running it under gdb. GDB was very quick at picking up a few errors, which
> were able to fix up. We then left the application running over night. An
> interesting thing that we noted, was that we needed to send 50% more
> telegrams per second to give the same percentage CPU usage loading on the
> application. The application simply runs much faster under Linux. A later
> test of the application compiled with the -O3 gave another 10% improvement
> in performance.


My experience is that Visual Studio produces binaries (from C) that are
several times slower than these which GCC generates. Same libraries,
somewhat different modularity (conjoining code).


> By the morning, we had a nice core dump and it was then trivial to find the
> offending code. I have read the Wintrolls write that it is possible to have
> a core dump produced by Windows, but I haven't been able to find how to do
> it. Maybe one of the trolls will actually explain how this is done. I
> suspect that this is just hot air.
> 
> Once we had the main problem cured, we then linked in electric fence and
> this found a few errors that Purify had not found. Most recently we have
> been running the application in valgrind and it has found even more errors.
> 
> Pretty well every Linux distro gives you all the tools required to develop
> professional programs. The equivalent tools for Windows would set you back
> thousands of dollars and they don't seem to work as well as the free tools
> you get with Linux.
> 
> If you want to produce professional code, Linux is the way to go. Now all
> that has to happen is the PHB's have to realize that the Microsoft FUD is
> pure lies and we will see a real sea change in the computer industry.


Did you actually believe that pricey software is indicative of quality? I
never did. The software I use in Linux is more stable than Windows
equivalents that I have experience with. Some of the best programmers are
those who wish to demonstrate their skills through Open Source projects such
as Apache. Other drop out and join that company in Redmond, which gives them
dim lights and towels, in exchange for VB code.

Tim Smith wrote:

> In article <104bb$44afb8d7$544a537b$32577@news.hispeed.ch>, Ian Hilliard
> wrote:
>> I am currently working for a Windows only house producing a system that
>> receives and transmits around 1000 telegrams per second in each direction
>> on a UDP socket, translates them into a different format and creates a
>> log entry for each telegram so that it can be processed off-line and
>> receives and sends the data to another application over a TCP/IP socket.
>> The program is multi-threaded and is written in C++. This is perhaps not
>> the ideal language, but it was a requirement that came down from on high,
>> when the original project was initiated.
> ...
>> I have a couple of firm rules: 1) All code is to be generic. Code that
>> works on only one platform does not belong to you, it belongs to the
>> platform.
> 
> If you limit yourself to generic code that works on all platforms, you put
> quite a constraint on performance, since you will be limited to select()
> for
> managing sockets.  That has scalability problems.  All major platforms
> have alternatives to select designed to get around this, but then the code
> isn't
> generic.  E.g., realtime signals on 2.4 Linux kernels, epoll on 2.6
> kernels, kqueue on *BSD, I-forget-what-it-is-called on Windows.
> 
> If you want to allow for maximum scalability, you are probably better off
> defining a generic interface to the network layer, and then allowing
> non-generic implementations of that interface.
> 
> It's a little dated now, but this article is very informative:
> 
>     <http://www.kegel.com/c10k.html>
> 

On the contrary, everything that is not generic goes into the abstraction
layer. It is then possible to make the generic calls to the abstraction
libraries. The library has things like an Event, a Mutex, a SingleLock, a
Thread, a ThreadManager, an InterThreadQueue template, etc... 

BTW, just because Microsoft has alternatives to select doesn't mean that
there is a problem with select. Select is not a signal. The select call
under Unix is a general workhorse that handles I/O events on anything with
a file descriptor. This makes it usable on files, pipes, I/O devices and
sockets. One select can handle any combination of devices.

The simple beauty of Unix makes it a pleasure to program. Windows only got a
foot hold because it was once upon a time a serious pain to do GUI's under
Unix. Added to that, Unix was far too expensive. That has all changed now.
It is about time that the unwashed masses of Windows programmers discovered
that there is a MUCH better way than Windows.

Ian

Ian Hilliard wrote:

> As Steve Balmer correctly stated, while making his monkey dance, it is
> applications and hence programmers that make a platform. The fact though
> is that if you want to do professional programming, then Linux is the
> platform for you. I know that this statement will get the heckels up on a
> lot of trolls in C.O.L.A, but I have a recent experience that proves this.
> 
> I am currently working for a Windows only house producing a system that
> receives and transmits around 1000 telegrams per second in each direction
> on a UDP socket, translates them into a different format and creates a log
> entry for each telegram so that it can be processed off-line and receives
> and sends the data to another application over a TCP/IP socket. The
> program is multi-threaded and is written in C++. This is perhaps not the
> ideal language, but it was a requirement that came down from on high, when
> the original project was initiated.
> 
> I had been in charge of the original production of this code, but a bunch
> of monkeys had been working on the code for a couple years and had made a
> complete mess of the program.
> 
> I have a couple of firm rules:
> 1) All code is to be generic. Code that works on only one platform does
> not belong to you, it belongs to the platform.
> 
> 2) All external interfaces have only one point of access. This includes
> API calls to the OS. I have an abstraction layer that provides an
> interface based on functional objects. It also provides a set of low level
> string handling functions and a set of standard objects for things like
> thread creation, synchronisation and inter-thread / inter-process
> communications.
> 
> The first thing I did when taking on the project is ran a number of
> different compilers over the code to find where non-standards coding had
> been used. I find that GCC 4.x is the most picky about coding errors.
> 
> Microsoft compilers are very willing to accept coding errors and in many
> cases do a reasonable job of interpreting the code. The problem is that
> all the compiler can do with non-standard code is attempt to guess what
> the programmer had in mind. The compiler may or may not get it correct.
> 
> This analysis together with a restructuring of the poorly designed
> sections fixed a lot of the problems in the code. It was then possible to
> put the new functionality into the project.
> 
> Around a month ago we finished programming and started putting the system
> through its paces. We found that there was a bug in the code that would
> cause cataclysmic failure of the program. At least with Windows 2003, the
> OS did not crash with application. We were not able to find the cause of
> the problem. The company, being an all Microsoft house has hundreds of
> thousands of dollars worth of tools like Rational Quantify/Purify and
> Bounds checker. It is really easy to spend a fortune on Windows
> programming tools, because they are so expensive. e.g. US$5000 for a
> single Quantify/Purify license.
> 
> We tried to find the cause of the failure with the large set of tools
> available to us. The problem always came back to the same thing. The
> program was gone and there was no way to know what state it was in when it
> died. Even running the program within Visual studio would cause Visual
> Studio to fail.
> 
> I finally gave up on the Windows tools and I ported the abstraction layer
> to Linux. I started by trying to port the solaris version of the
> abstraction layer, but then discovered that there is a really good site at
> www-128.ibm.com/developerworks that gives some easy steps to port Windows
> code to Linux. After a weekend of porting the abstraction library, it was
> a trivial task to compile the application and get it running under Linux.
> The only real catch in the whole process was with select. The rfds to be
> passed in is the the highest socket ID plus 1. That is a little different
> to the unix versions I've used, where the number of entries in the fd_set
> is passed in and very different to Windows, where -1 is always passed in.
> 
> The next step was to put a second partition onto the test machine. That is
> an easy task these days. We compiled the application with -g and started
> running it under gdb. GDB was very quick at picking up a few errors, which
> were able to fix up. We then left the application running over night. An
> interesting thing that we noted, was that we needed to send 50% more
> telegrams per second to give the same percentage CPU usage loading on the
> application. The application simply runs much faster under Linux. A later
> test of the application compiled with the -O3 gave another 10% improvement
> in performance.
> 
> By the morning, we had a nice core dump and it was then trivial to find
> the offending code. I have read the Wintrolls write that it is possible to
> have a core dump produced by Windows, but I haven't been able to find how
> to do it. Maybe one of the trolls will actually explain how this is done.
> I suspect that this is just hot air.
> 
> Once we had the main problem cured, we then linked in electric fence and
> this found a few errors that Purify had not found. Most recently we have
> been running the application in valgrind and it has found even more
> errors.
> 
> Pretty well every Linux distro gives you all the tools required to develop
> professional programs. The equivalent tools for Windows would set you back
> thousands of dollars and they don't seem to work as well as the free tools
> you get with Linux.
> 
> If you want to produce professional code, Linux is the way to go. Now all
> that has to happen is the PHB's have to realize that the Microsoft FUD is
> pure lies and we will see a real sea change in the computer industry.
> 
> Ian


Nowadays, I spend a few days writing code in Gambas
http://gambas.sourceforge.net
in the free developer environments like KDevelop,
gcc, khexedit, kwrite, kompare and when I know it works,
I port it to windopes where I know I have to spend three months fixing it.
I am not allowed incorporate third party controls, particulary as their
owners can die rendering the entire product unsupportable overnight.
Open source doesn't have those problems, particularly as I can dig into
source code and configuration files to repair issues.

billwg wrote:

> 
> "Ian Hilliard" <nospam@hilliardtech.com> wrote in message
> news:104bb$44afb8d7$544a537b$32577@news.hispeed.ch...
>>
> Why don't you get your employer to pay a little bit to send you to a
> debug techniques class, Ian, then you wouldn't look like such an idiot.

Why don't you spend your remaining few cents on a reading class (absolute
beginners)?
-- 
Microsoft's Guide To System Design:
        Let it get in YOUR way. The problem for your problem.

After takin' a swig o' grog, Ian Hilliard belched out this bit o' wisdom:

> As Steve Balmer correctly stated, while making his monkey dance, it is
> applications and hence programmers that make a platform. The fact though is
> that if you want to do professional programming, then Linux is the platform
> for you. I know that this statement will get the heckels up on a lot of
> trolls in C.O.L.A, but I have a recent experience that proves this.
>
> I am currently working for a Windows only house producing a system that
> receives and transmits around 1000 telegrams per second in each direction
> on a UDP socket, translates them into a different format and creates a log
> entry for each telegram so that it can be processed off-line and receives
> and sends the data to another application over a TCP/IP socket. The program
> is multi-threaded and is written in C++. This is perhaps not the ideal
> language, but it was a requirement that came down from on high, when the
> original project was initiated.
>
> I had been in charge of the original production of this code, but a bunch of
> monkeys had been working on the code for a couple years and had made a
> complete mess of the program.
>
> I have a couple of firm rules:
> 1) All code is to be generic. Code that works on only one platform does not
> belong to you, it belongs to the platform.
>
> 2) All external interfaces have only one point of access. This includes API
> calls to the OS. I have an abstraction layer that provides an interface
> based on functional objects. It also provides a set of low level string
> handling functions and a set of standard objects for things like thread
> creation, synchronisation and inter-thread / inter-process communications.
>
> The first thing I did when taking on the project is ran a number of
> different compilers over the code to find where non-standards coding had
> been used. I find that GCC 4.x is the most picky about coding errors.
>
> Microsoft compilers are very willing to accept coding errors and in many
> cases do a reasonable job of interpreting the code. The problem is that all
> the compiler can do with non-standard code is attempt to guess what the
> programmer had in mind. The compiler may or may not get it correct.
>
> This analysis together with a restructuring of the poorly designed sections
> fixed a lot of the problems in the code. It was then possible to put the
> new functionality into the project.
>
> Around a month ago we finished programming and started putting the system
> through its paces. We found that there was a bug in the code that would
> cause cataclysmic failure of the program. At least with Windows 2003, the
> OS did not crash with application. We were not able to find the cause of
> the problem. The company, being an all Microsoft house has hundreds of
> thousands of dollars worth of tools like Rational Quantify/Purify and
> Bounds checker. It is really easy to spend a fortune on Windows programming
> tools, because they are so expensive. e.g. US$5000 for a single
> Quantify/Purify license.
>
> We tried to find the cause of the failure with the large set of tools
> available to us. The problem always came back to the same thing. The
> program was gone and there was no way to know what state it was in when it
> died. Even running the program within Visual studio would cause Visual
> Studio to fail.
>
> I finally gave up on the Windows tools and I ported the abstraction layer to
> Linux. I started by trying to port the solaris version of the abstraction
> layer, but then discovered that there is a really good site at
> www-128.ibm.com/developerworks that gives some easy steps to port Windows
> code to Linux. After a weekend of porting the abstraction library, it was a
> trivial task to compile the application and get it running under Linux. The
> only real catch in the whole process was with select. The rfds to be passed
> in is the the highest socket ID plus 1. That is a little different to the
> unix versions I've used, where the number of entries in the fd_set is
> passed in and very different to Windows, where -1 is always passed in.
>
> The next step was to put a second partition onto the test machine. That is
> an easy task these days. We compiled the application with -g and started
> running it under gdb. GDB was very quick at picking up a few errors, which
> were able to fix up. We then left the application running over night. An
> interesting thing that we noted, was that we needed to send 50% more
> telegrams per second to give the same percentage CPU usage loading on the
> application. The application simply runs much faster under Linux. A later
> test of the application compiled with the -O3 gave another 10% improvement
> in performance.
>
> By the morning, we had a nice core dump and it was then trivial to find the
> offending code. I have read the Wintrolls write that it is possible to have
> a core dump produced by Windows, but I haven't been able to find how to do
> it. Maybe one of the trolls will actually explain how this is done. I
> suspect that this is just hot air.
>
> Once we had the main problem cured, we then linked in electric fence and
> this found a few errors that Purify had not found. Most recently we have
> been running the application in valgrind and it has found even more errors.
>
> Pretty well every Linux distro gives you all the tools required to develop
> professional programs. The equivalent tools for Windows would set you back
> thousands of dollars and they don't seem to work as well as the free tools
> you get with Linux.
>
> If you want to produce professional code, Linux is the way to go. Now all
> that has to happen is the PHB's have to realize that the Microsoft FUD is
> pure lies and we will see a real sea change in the computer industry.

I've experienced a lot of what you say above.

One minor addition... I like to pop between Windows and Linux as I
develop a project.  Often one environment will complain about something
the other one misses.

I'm sure I haven't used the full debugging power of Visual Studio.  It
provides ways to detect leakage (at the cost of tinkering with your
code).  But valgrind does just that... grinds and grinds, and can really
make you embarrassed at the stuff you missed (or at stuff that other OSS
coders missed!)

One more thing.  As far as I know, Windows has nothing to compare with
the GNU autotools.

-- 
   "These changes do mean that we are not pursuing a separate delivery of
   WinFS ....  With most of our effort now working towards productizing mature
 aspects of the WinFS project into SQL and ADO.NET, we do not need to deliver
   a separate WinFS offering. -- Quentin Clark on the WinFS Team Blog

billwg wrote:

> 
> "Ian Hilliard" <nospam@hilliardtech.com> wrote in message
> news:104bb$44afb8d7$544a537b$32577@news.hispeed.ch...
>>
> Why don't you get your employer to pay a little bit to send you to a
> debug techniques class, Ian, then you wouldn't look like such an idiot.

You try finding a race condition in a multi threaded application that causes
an application to totally dissappear and Windows XP to crash and burn. 

Without core dumps it is nearly impossible to see what state the application
was in at the moment that it died. I guess that you will have to stop
writing toy programs in Excel Basic and start writing real-time
applications, before you really understand what problems are associated
with meeting real-time deadlines.

You must work hard at behaving like such an idiot. Anyone that was truly as
stupid as your COLA persona would have long since been a contender for a
Darwin Award.

Ian

After takin' a swig o' grog, Ian Hilliard belched out this bit o' wisdom:

> billwg wrote:
>
>> Why don't you get your employer to pay a little bit to send you to a
>> debug techniques class, Ian, then you wouldn't look like such an idiot.
>
> You must work hard at behaving like such an idiot. Anyone that was truly as
> stupid as your COLA persona would have long since been a contender for a
> Darwin Award.

His forte is useless blather.  Sort of like Bill "Pearly" Gates, only
more sour and stupid.

-- 
   Yes, I've heard of "decaf." What's your point?

Ian Hilliard wrote:
> billwg wrote:
>
>>
>> "Ian Hilliard" <nospam@hilliardtech.com> wrote in message
>> news:104bb$44afb8d7$544a537b$32577@news.hispeed.ch...
>>>
>> Why don't you get your employer to pay a little bit to send you to a
>> debug techniques class, Ian, then you wouldn't look like such an
>> idiot.
>
> You try finding a race condition in a multi threaded application that
> causes an application to totally dissappear and Windows XP to crash
> and burn.

ffs, you wrote the program!  Why are you trying to blame all the problems on 
other coders, on Windows tools, and on PHB's?



> Without core dumps it is nearly impossible to see what state the
> application was in at the moment that it died. I guess that you will
> have to stop writing toy programs in Excel Basic

I also [sometimes] write Excel VBA programs (maybe billwg does too), but 
they're not toy programs.  My clients make big-money decisions based on the 
information processed and presented in my systems.

And, my "toy" programs don't crash the app; yours do.



> and start writing real-time applications, before you
> really understand what problems are associated with
> meeting real-time deadlines.

If you're not up to it, you need to tell your company, and turn the project 
over to someone more capable.



> You must work hard at behaving like such an idiot. Anyone that was
> truly as stupid as your COLA persona would have long since been a
> contender for a Darwin Award.

He means well, don't you think?  Instead of blaming your problems on Windows 
tools, and other coders (or MCSE's as Kelsey Bjarnason likes to do), why 
don't you take billwg's advice and attend more programming classes?

Thanks for taking the trouble to explain your work in such detail.  I
enjoy reading real world experiences such as yours more than anything
in this newsgroup.

"Ian Hilliard" <nospam@hilliardtech.com> wrote in message 
news:a76e2$44b1389c$544a537b$12302@news.hispeed.ch...
> billwg wrote:
>
>>
>> "Ian Hilliard" <nospam@hilliardtech.com> wrote in message
>> news:104bb$44afb8d7$544a537b$32577@news.hispeed.ch...
>>>
>> Why don't you get your employer to pay a little bit to send you to a
>> debug techniques class, Ian, then you wouldn't look like such an 
>> idiot.
>
> You try finding a race condition in a multi threaded application that 
> causes
> an application to totally dissappear and Windows XP to crash and burn.
>

Better to not put any race conditions into the code in the first place, 
silly!  Where'd you go to school?

> Without core dumps it is nearly impossible to see what state the 
> application
> was in at the moment that it died. I guess that you will have to stop
> writing toy programs in Excel Basic and start writing real-time
> applications, before you really understand what problems are 
> associated
> with meeting real-time deadlines.
>
> You must work hard at behaving like such an idiot. Anyone that was 
> truly as
> stupid as your COLA persona would have long since been a contender for 
> a
> Darwin Award.
>
You are the dumb ass that seems to think that the Windows debug tools 
cannot generate a memory dump and needs to trot his ignorance out as a 
badge of heroic action, ian!  If you paid more attention to what you 
were hired to do, you would know how to do that without coming up with 
the silly run-around that you described.  Since you didn't bother to 
mention the obvious, I can only assume that you never heard of cdb or 
windbg, presumably because you lack the basic understanding to even look 
in the right place.  Look them up and save yourself a lot of time the 
next time.  They're free, too. 

After takin' a swig o' grog, DFS belched out this bit o' wisdom:

> Ian Hilliard wrote:
>> billwg wrote:
>>
>>> Why don't you get your employer to pay a little bit to send you to a
>>> debug techniques class, Ian, then you wouldn't look like such an
>>> idiot.
>>
>> You try finding a race condition in a multi threaded application that
>> causes an application to totally dissappear and Windows XP to crash
>> and burn.
>
> ffs, you wrote the program!  Why are you trying to blame all the problems on 
> other coders, on Windows tools, and on PHB's?

Let me get this straight.  You think an OS bombing out a debugging app
and crashing an OS is the fault of a user app?

> I also [sometimes] write Excel VBA programs (maybe billwg does too), but 
> they're not toy programs.  My clients make big-money decisions based on the 
> information processed and presented in my systems.
>
> And, my "toy" programs don't crash the app; yours do.

There's a world of difference between multi-threaded apps and data
crunchers.

> He means well, don't you think?  Instead of blaming your problems on Windows 
> tools, and other coders (or MCSE's as Kelsey Bjarnason likes to do), why 
> don't you take billwg's advice and attend more programming classes?

Programming classes are mostly a waste of time.

-- 
   "No! There are no significant bugs in our released software that any
 significant number of users want fixed." -- Bill Gates, FOCUS interview
   http://www.cantrip.org/nobugs.html

Linonut wrote:
> After takin' a swig o' grog, DFS belched out this bit o' wisdom:
>
>> Ian Hilliard wrote:
>>> billwg wrote:
>>>
>>>> Why don't you get your employer to pay a little bit to send you to
>>>> a debug techniques class, Ian, then you wouldn't look like such an
>>>> idiot.
>>>
>>> You try finding a race condition in a multi threaded application
>>> that causes an application to totally dissappear and Windows XP to
>>> crash and burn.
>>
>> ffs, you wrote the program!  Why are you trying to blame all the
>> problems on other coders, on Windows tools, and on PHB's?
>
> Let me get this straight.  You think an OS bombing out a debugging app
> and crashing an OS is the fault of a user app?

Sounds like it here.



>> I also [sometimes] write Excel VBA programs (maybe billwg does too),
>> but they're not toy programs.  My clients make big-money decisions
>> based on the information processed and presented in my systems.
>>
>> And, my "toy" programs don't crash the app; yours do.
>
> There's a world of difference between multi-threaded apps and data
> crunchers.

Quit defending his slopware.




>> He means well, don't you think?  Instead of blaming your problems on
>> Windows tools, and other coders (or MCSE's as Kelsey Bjarnason likes
>> to do), why don't you take billwg's advice and attend more
>> programming classes?
>
> Programming classes are mostly a waste of time.

Depends on who teaches them.  If it's some OSS weirdo ranting about "the MS 
VC++ compiler lets this through, but gcc 3.4.6 catches it.  RMS is god!" 
then I would agree.

begin  oe_protect.scr 
Linonut <linonut@bone.com> espoused:
> After takin' a swig o' grog, Ian Hilliard belched out this bit o' wisdom:
> 
>> billwg wrote:
>>
>>> Why don't you get your employer to pay a little bit to send you to a
>>> debug techniques class, Ian, then you wouldn't look like such an idiot.
>>
>> You must work hard at behaving like such an idiot. Anyone that was truly as
>> stupid as your COLA persona would have long since been a contender for a
>> Darwin Award.
> 
> His forte is useless blather.  Sort of like Bill "Pearly" Gates, only
> more sour and stupid.
> 

Don't know why anyone bothers to respond to him, to be honest.  He's
only there to provoke; when questioned he falls back onto inanity.  Not
worth the bandwidth.

-- 
| Mark Kent   --   mark at ellandroad dot demon dot co dot uk  |
To be intoxicated is to feel sophisticated but not be able to say it.

"Linonut" <linonut@bone.com> wrote in message 
news:fNadnWs8kdGfLSzZnZ2dnUVZ_uidnZ2d@comcast.com...
>
> Programming classes are mostly a waste of time.
>
Only for slow learners, nut!  LOL!!!  Do you remember the bumper sticker 
"If you think education is expensive, try ignorance!"?  Ian, is a case 
right on point. 

After takin' a swig o' grog, DFS belched out this bit o' wisdom:

> Linonut wrote:
>> There's a world of difference between multi-threaded apps and data
>> crunchers.
>
> Quit defending his slopware.

I seriously doubt it is his slopware.

For one thing, if you read what he said, a number of other people
screwed around with his code.

Also, unless you've spent a solid year or two working on multi-threaded
code, you probably do not understand just how difficult such code can be
to get working correctly.

Often, you can get it working on a single-processor system, and have it
collapse on a real SMP system.

I seriously doubt Ian writes "slopware".

>>> He means well, don't you think?  Instead of blaming your problems on
>>> Windows tools, and other coders (or MCSE's as Kelsey Bjarnason likes
>>> to do), why don't you take billwg's advice and attend more
>>> programming classes?
>>
>> Programming classes are mostly a waste of time.
>
> Depends on who teaches them.  If it's some OSS weirdo ranting about "the MS 
> VC++ compiler lets this through, but gcc 3.4.6 catches it.  RMS is god!" 
> then I would agree.

No.  Most programming classes are too basic to be useful to anyone with
a few years actual experience coding and debugging.  Programming classes
can help, but, at best, they are merely introductions to their topics.

-- 
   Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.

On 2006-07-08, Ian Hilliard <nospam@hilliardtech.com> wrote:
> The next step was to put a second partition onto the test machine. That is
> an easy task these days. We compiled the application with -g and started
> running it under gdb. GDB was very quick at picking up a few errors, which
> were able to fix up.

 Porting is a great way to find many classes of errors, particularly
memory errors. A silent corruption on one system can be an immediate
crash on another. Then there's simple things like the MALLOC_CHECK_
environment variable...

-- 
 Sincerely,

 Ray Ingles                                       (313) 227-2317

 Gillette plans on spending $300 million to promote a razor that
 cost $750 million to develop. And people complain about 'waste'
 when private donations totalling $134,500 are spent on SETI...

DFS wrote:

> ffs, you wrote the program!  Why are you trying to blame all the problems
> on other coders, on Windows tools, and on PHB's?
> 

Maybe one day you will learn to read.

The problem was that I had lead the team that wrote the original program. It
was then handed over to another crew for maintenance and expansion, as
necessary. This team of Microsoft only monkeys totally screwed up the code.
They on the other hand had a better excuse than you to not understand the
design documents. Many of them could barely read English. Unlike you, they
admitted their inability to read English.

The company brought me back to get the project back on track because it is
to be used in a very large project worth over 100 Million Pounds Stirling.

Whether you like it or not, Basic is a very simple language designed for
NON-programmers. Secondly, there is a huge difference between a program
designed for number crunching and a program that has to meet hard
deadlines.

This particular program has one millisecond to read a message off a socket,
bit-wise interpret the message, based on formats, which can change, write a
log entry for the message, translate the message into generic format and
send it over a TCP connection to another subsystem and do the reverse in
the reverse direction at the same time. The application has to run
24/7/365, meeting 99.999% reliability. This is a completely different game
to writing Excel spread sheets.

Finally, I would suggest that you keep quiet about those thing which you
don't know. You only make yourself look stupider than people already
believe you to be.

Ian

On 2006-07-10, billwg <billw@twcf.rr.com> wrote:
> Better to not put any race conditions into the code in the first place, 
> silly!  Where'd you go to school?

 What school did you go to that allows you to write flawless and
completely bug-free code? I haven't heard of them, and you'd think
they'd be famous by now...

-- 
 Sincerely,

 Ray Ingles                                          (313) 227-2317

   Something must be done! This is something, so it must be done.
                      - Politician's Logic

DFS wrote:

> Quit defending his slopware.
> 

The whole point is there is a serious weakness in Windows that it doesn't
give you core dumps. There is hence no way of knowing what state the
application was in when it died. If an operating system is really serious
about being a developers platform, it needs to give you an indication what
caused the application to crash. Bringing up the development environment
just doesn't cut it when an application has completely gone south.

I have already made this point. I would try to have an intelligent
conversation with you, but seeing you are clearly less intelligent than a
wall, I might as well speak to the wall. At least it doesn't post stupid
comments like you.



Ian

Ian Hilliard wrote:
> DFS wrote:
>
>> Quit defending his slopware.
>
> The whole point is there is a serious weakness in Windows that it
> doesn't give you core dumps. There is hence no way of knowing what
> state the application was in when it died. If an operating system is
> really serious about being a developers platform, it needs to give
> you an indication what caused the application to crash. Bringing up
> the development environment just doesn't cut it when an application
> has completely gone south.

This is some kind of joke or sidestep, right?  How many countless thousands 
of stable, commercial Windows apps - single and multi-threaded - have been 
developed and debugged on Windows systems with Windows tools?

Certainly there is a Windows tool out there to help fix your code.  Don't 
make me research it for you.

It's not the OS' responsibility to tell you why your app failed.  The app 
itself should do that.  You do utilize error trapping?







> I have already made this point. I would try to have an intelligent
> conversation with you, but seeing you are clearly less intelligent
> than a wall, I might as well speak to the wall. At least it doesn't
> post stupid comments like you.
>
>
>
> Ian 

nessuno@wigner.berkeley.edu wrote:

> Thanks for taking the trouble to explain your work in such detail.  I
> enjoy reading real world experiences such as yours more than anything
> in this newsgroup.

I am glad you enjoyed it. 

I have been is the software project management business for a very long
time. As such, there are a few truisms that keep proving their worth.

Only the operating system abstraction layer can be platform dependant. All
other code must be platform agnostic. This opens doors to many different
possabilities. Many of which you won't see when you start the project. 

The application must be broken down into small segments, each with a small
well defined (and documented) interface to others.

Where a new function is being developed, try to keep it as generic as
possible. This may mean having to break it into a generic and a non-generic
section. It is quite likely that you will be able to reuse the generic
section elsewhere in the same project or in another project.

A prototype is simply the the first release of a new product line. Ensure
that the prototype is well designed and designed to be expanded in ways
that are not yet defined.

Ensure that all the business rules and software structure are defined before
writing a single line of code. 

Where it is not possible to define ALL the business rules, produce a design
with a well defined scope for handling the yet undefined business rules. In
other words, the design must include the areas where the yet undefined
business rules will be coded.

All code has faults. The trick is to catch as many faults as possible before
shipping.

If it isn't tested, it doesn't work. 

Regards,
Ian

Ian Hilliard wrote:

> nessuno@wigner.berkeley.edu wrote:
> 
>> Thanks for taking the trouble to explain your work in such detail.  I
>> enjoy reading real world experiences such as yours more than anything
>> in this newsgroup.
> 
> I am glad you enjoyed it.
> 
> I have been is the software project management business for a very long
> time. As such, there are a few truisms that keep proving their worth.
> 
> Only the operating system abstraction layer can be platform dependant. All
> other code must be platform agnostic. This opens doors to many different
> possabilities. Many of which you won't see when you start the project.
> 
> The application must be broken down into small segments, each with a small
> well defined (and documented) interface to others.
> 
> Where a new function is being developed, try to keep it as generic as
> possible. This may mean having to break it into a generic and a
> non-generic section. It is quite likely that you will be able to reuse the
> generic section elsewhere in the same project or in another project.
> 
> A prototype is simply the the first release of a new product line. Ensure
> that the prototype is well designed and designed to be expanded in ways
> that are not yet defined.
> 
> Ensure that all the business rules and software structure are defined
> before writing a single line of code.
> 
> Where it is not possible to define ALL the business rules, produce a
> design with a well defined scope for handling the yet undefined business
> rules. In other words, the design must include the areas where the yet
> undefined business rules will be coded.
> 
> All code has faults. The trick is to catch as many faults as possible
> before shipping.
> 
> If it isn't tested, it doesn't work.
> 
> Regards,
> Ian

A few more that come to mind.

Always write code with the thought in mind that the next person to work on
the code may just be you, in three years.

Comments should explain why you are doing something. The code should be
clearly enough written to understand what you are doing.

Complex solutions don't work. The best solution is always the simplest that
meets the requirements.

KISS (Keep It Simple Stupid) or (Keep it Small and Simple) (Take your pick
and shovel, if you want :)

Complex problems are solved by putting together simple solutions in
intelligent ways.

An archer without a target will never hit the bullseye. So, define your
target before you cock you bow.

True genius is the ability to find simple patterns in complex problems. True
academia is the ability to find complex problems in simple patterns.

Regards,
Ian

DFS wrote:

> This is some kind of joke or sidestep, right?  How many countless
> thousands of stable, commercial Windows apps - single and multi-threaded -
> have been developed and debugged on Windows systems with Windows tools?
> 

No, many many incredibly buggy and crappy desktop applications have been
developed for Windows. With these applications, it doesn't matter if they
crash from time to time. The user simply restarts and gets on with the job.
It's the Windows way.

> Certainly there is a Windows tool out there to help fix your code.  Don't
> make me research it for you.

The company has a very full set of tools, but when compiled in they changed
the behaviour of the system so much that the race condition did not occur.

The problem has been solved already and using tools for which I didn't have
to come up with a budget request for. Pretty well every Linux distro comes
with a rich set of development tools FOR FREE.

> 
> It's not the OS' responsibility to tell you why your app failed.  The app
> itself should do that.  You do utilize error trapping?
> 

It is this stupid narrow minded thinking that keeps Windows such a second
rate platform. There are some classes or errors which cause cataclysmic
failure, even where there is error trapping. The best solution to this
class of problem is a core dump.

I suggest you get back to your Basic programming and leave the real
programming to the professionals.

Ian

Linonut wrote:
> After takin' a swig o' grog, DFS belched out this bit o' wisdom:
>
>> Linonut wrote:
>>> There's a world of difference between multi-threaded apps and data
>>> crunchers.
>>
>> Quit defending his slopware.
>
> I seriously doubt it is his slopware.
>
> For one thing, if you read what he said, a number of other people
> screwed around with his code.

I've noticed with cola nuts it's always an MCSE or "Microsoft monkeys" or 
some MS technology that causes all their problems in life.

And apparently, cola bozos are the world's most inept Windows users. 
Hundreds of millions of users get on with their lives, merrily working away 
day and night on fast, stable Windows systems.  But let a cola nut look at 
XP and it supposedly blue screens.




> Also, unless you've spent a solid year or two working on
> multi-threaded code, you probably do not understand just how
> difficult such code can be to get working correctly.
>
> Often, you can get it working on a single-processor system, and have
> it collapse on a real SMP system.

More excuses by and for a cola "advocate".  But if MS doesn't get everything 
exactly right, you and a dozen other cola whiners bitch and moan.

Ian Hilliard wrote:
> DFS wrote:
>
>> This is some kind of joke or sidestep, right? � How many countless
>> thousands of stable, commercial Windows apps - single and
>> multi-threaded - have been developed and debugged on Windows systems
>> with Windows tools?
>
> No, many many incredibly buggy and crappy desktop applications have
> been developed for Windows. With these applications, it doesn't
> matter if they crash from time to time. The user simply restarts and
> gets on with the job. It's the Windows way.

By that measure, it's the Linux/OSS way as well, 'cause based on per hour of 
usage, I have experienced far, far more unstable, crashing, freezing apps in 
the few months I've used Linux than in years of using Windows.



>> Certainly there is a Windows tool out there to help fix your code. �
>> Don't make me research it for you.
>
> The company has a very full set of tools, but when compiled in they
> changed the behaviour of the system so much that the race condition
> did not occur.
>
> The problem has been solved already and using tools for which I
> didn't have to come up with a budget request for. Pretty well every
> Linux distro comes with a rich set of development tools FOR FREE.

Yet your company chooses to buy commercial tools.  Why?



>> It's not the OS' responsibility to tell you why your app failed. �
>> The app itself should do that. � You do utilize error trapping?
>>
>
> It is this stupid narrow minded thinking that keeps Windows such a
> second rate platform. There are some classes or errors which cause
> cataclysmic failure, even where there is error trapping. The best
> solution to this class of problem is a core dump.

The best solution, in any language, is to write solid code in the first 
place.  Then you don't have to blame your problems on others, on Windows, 
etc.




> I suggest you get back to your Basic programming and leave the real
> programming to the professionals.

What professionals would you be talking about?

Only an immature clown would consider Basic programming to not be real 
programming.  And it figures a biased, anti-MS ignoramus like you wouldn't 
know that you can write multi-threaded Visual Basic apps.

Ian Hilliard wrote:
> nessuno@wigner.berkeley.edu wrote:
>
>> Thanks for taking the trouble to explain your work in such detail.  I
>> enjoy reading real world experiences such as yours more than anything
>> in this newsgroup.

I don't agree with your whiny bitching about Windows, but I also appreciate 
the detailed explanations.  It sounds like an interesting project to work 
on.

You said:
==========================
This particular program has one millisecond to read a message off a socket,
bit-wise interpret the message, based on formats, which can change, write a
log entry for the message, translate the message into generic format and
send it over a TCP connection to another subsystem and do the reverse in
the reverse direction at the same time. The application has to run
24/7/365, meeting 99.999% reliability. This is a completely different game
to writing Excel spread sheets.
==========================

Where in this process do you spawn and kill threads?

(as far as 99.999% reliability, that requirement had to have been dropped a 
long time ago - if the program crashes and is down for more than 5.25 
minutes).

Just so you know, I've done similar work in VB (read incoming messages and 
data, write log entries, send them off), but not multithreaded, not in 
milliseconds, and not expected to be 99.999% reliable.  But still important 
systems.

After takin' a swig o' grog, DFS belched out this bit o' wisdom:

> Ian Hilliard wrote:
>> DFS wrote:
>>
>>> Quit defending his slopware.
>>
>> The whole point is there is a serious weakness in Windows that it
>> doesn't give you core dumps. There is hence no way of knowing what
>> state the application was in when it died. If an operating system is
>> really serious about being a developers platform, it needs to give
>> you an indication what caused the application to crash. Bringing up
>> the development environment just doesn't cut it when an application
>> has completely gone south.
>
> This is some kind of joke or sidestep, right?  How many countless thousands 
> of stable, commercial Windows apps - single and multi-threaded - have been 
> developed and debugged on Windows systems with Windows tools?

Name one stable multi-threaded windows app.

Visual Studio may come close.

Windows Explorer doesn't.

Outlook?  What a piece of crap.

> Certainly there is a Windows tool out there to help fix your code.  Don't 
> make me research it for you.
>
> It's not the OS' responsibility to tell you why your app failed.  The app 
> itself should do that.  You do utilize error trapping?

The debugger should, too.

However, core dumps would be helpful.  You can load them in gdb and
figure out what happened.  They are an audit trail into what happened.

Those Dr. Watson thingies have some info.  Not as much as a core dump.

-- 
   "These changes do mean that we are not pursuing a separate delivery of
   WinFS ....  With most of our effort now working towards productizing mature
 aspects of the WinFS project into SQL and ADO.NET, we do not need to deliver
   a separate WinFS offering. -- Quentin Clark on the WinFS Team Blog

After takin' a swig o' grog, DFS belched out this bit o' wisdom:

>> I suggest you get back to your Basic programming and leave the real
>> programming to the professionals.
>
> What professionals would you be talking about?
>
> Only an immature clown would consider Basic programming to not be real 
> programming.  And it figures a biased, anti-MS ignoramus like you wouldn't 
> know that you can write multi-threaded Visual Basic apps.

Basic programming has never seemed all that attractive to me.

However, you can programming significant apps in any language.

-- 
   I'd rather have a bottle in front of me
   than a frontal lobotomy.

After takin' a swig o' grog, DFS belched out this bit o' wisdom:

> Linonut wrote:
>> After takin' a swig o' grog, DFS belched out this bit o' wisdom:
>>
>>> Linonut wrote:
>>>> There's a world of difference between multi-threaded apps and data
>>>> crunchers.
>>>
>>> Quit defending his slopware.
>>
>> I seriously doubt it is his slopware.
>>
>> For one thing, if you read what he said, a number of other people
>> screwed around with his code.
>
> I've noticed with cola nuts it's always an MCSE or "Microsoft monkeys" or 
> some MS technology that causes all their problems in life.
>
> And apparently, cola bozos are the world's most inept Windows users. 
> Hundreds of millions of users get on with their lives, merrily working away 
> day and night on fast, stable Windows systems.  But let a cola nut look at 
> XP and it supposedly blue screens.

In my experience, Windows coders get so used to working around problems
that they almost forget about them.

Until something blows up a few months later.

-- 
   ...and that is how we know the Earth to be banana-shaped.

Linonut wrote:
> After takin' a swig o' grog, DFS belched out this bit o' wisdom:
>
>> Ian Hilliard wrote:
>>> DFS wrote:
>>>
>>>> Quit defending his slopware.
>>>
>>> The whole point is there is a serious weakness in Windows that it
>>> doesn't give you core dumps. There is hence no way of knowing what
>>> state the application was in when it died. If an operating system is
>>> really serious about being a developers platform, it needs to give
>>> you an indication what caused the application to crash. Bringing up
>>> the development environment just doesn't cut it when an application
>>> has completely gone south.
>>
>> This is some kind of joke or sidestep, right?  How many countless
>> thousands of stable, commercial Windows apps - single and
>> multi-threaded - have been developed and debugged on Windows systems
>> with Windows tools?
>
> Name one stable multi-threaded windows app.


> Visual Studio may come close.
>
> Windows Explorer doesn't.
>
> Outlook?  What a piece of crap.

Outlook's a good email client/calendaring system.  Millions of people and 
businesses totally depend on it.  It sure beats up on something slow and OSS 
like Thunderbird.

Outlook Express is OK, too.  It's very stable and fast (at least on my 
WinServer2003 box).  It has news and email right there.  It has passable 
filtering, block senders, multiple identities, options to read/send text 
only, various encoding options, options for composing, signatures, etc. 
Import/export address books, etc.

I think you're just being a cola moron so you can fit in.






>> Certainly there is a Windows tool out there to help fix your code.
>> Don't make me research it for you.
>>
>> It's not the OS' responsibility to tell you why your app failed.
>> The app itself should do that.  You do utilize error trapping?
>
> The debugger should, too.
>
> However, core dumps would be helpful.  You can load them in gdb and
> figure out what happened.  They are an audit trail into what happened.
>
> Those Dr. Watson thingies have some info.  Not as much as a core dump.

Without doing too much research, it seems Windows (2000 anyway) has tools to 
get core dumps

http://labmice.techtarget.com/troubleshooting/memorydumps.htm

Linonut wrote:
> After takin' a swig o' grog, DFS belched out this bit o' wisdom:
>
>>> I suggest you get back to your Basic programming and leave the real
>>> programming to the professionals.
>>
>> What professionals would you be talking about?
>>
>> Only an immature clown would consider Basic programming to not be
>> real programming.  And it figures a biased, anti-MS ignoramus like
>> you wouldn't know that you can write multi-threaded Visual Basic
>> apps.
>
> Basic programming has never seemed all that attractive to me.

I'ts OK.  It doesn't get in the way (like Java or C would) and helps me 
accomplish what I like to do, and what my clients pay me to do: develop 
visual, event-driven interface systems to capture, retrieve, manipulate and 
display data against relational data stores.

I worked with a guy who loved tweaking his server-side Java code.  Didn't 
appeal to me.



> However, you can programming significant apps in any language.

Yes.

Speaking of significant, I wonder what is the "largest" (lines of code, I 
guess) program?  Oracle?  Windows Vista?  Linux kernel?

DFS wrote:

>  And it figures a biased, anti-MS ignoramus like you wouldn't 
> know that you can write multi-threaded Visual Basic apps.

That's only really been true since VB.NET

Yes, there was a Thread object in VB6 and you could use the Timer in 
thread-line ways...but it was still almost impossible.

Also, VB.NET is still has single class inheritance.

DFS wrote:
> Linonut wrote:
> > After takin' a swig o' grog, DFS belched out this bit o' wisdom:
> >
> >> Linonut wrote:
> >>> There's a world of difference between multi-threaded apps and data
> >>> crunchers.
> >>
> >> Quit defending his slopware.
> >
> > I seriously doubt it is his slopware.
> >
> > For one thing, if you read what he said, a number of other people
> > screwed around with his code.
>
> I've noticed with cola nuts it's always an MCSE or "Microsoft monkeys" or
> some MS technology that causes all their problems in life.
>
> And apparently, cola bozos are the world's most inept Windows users.
> Hundreds of millions of users get on with their lives, merrily working away
> day and night on fast, stable Windows systems.  But let a cola nut look at
> XP and it supposedly blue screens.
>


Notice how all the cola nuts cry and complain about windows but when it
comes to work and making a living they all write Windows code for a
living.

>
> > Also, unless you've spent a solid year or two working on
> > multi-threaded code, you probably do not understand just how
> > difficult such code can be to get working correctly.
> >
> > Often, you can get it working on a single-processor system, and have
> > it collapse on a real SMP system.
>
> More excuses by and for a cola "advocate".  But if MS doesn't get everything
> exactly right, you and a dozen other cola whiners bitch and moan.

Ginsu Warrior wrote:

> Notice how all the cola nuts cry and complain about windows but when it
> comes to work and making a living they all write Windows code for a
> living.

Most write .Net (VB, c) code and java for a living.

Both of those are cross platform for Linux and Windows.

And if they weren't -- they would never have taken off...

After takin' a swig o' grog, DFS belched out this bit o' wisdom:

> Outlook's a good email client/calendaring system.  Millions of people and 
> businesses totally depend on it.  It sure beats up on something slow and OSS 
> like Thunderbird.

No, it doesn't.  It is crap.  A dropped connection or instantiation of
VPN renders it immobile.  You can't even exit it easily.

> Outlook Express is OK, too.  It's very stable and fast (at least on my 
> WinServer2003 box).  It has news and email right there.  It has passable 
> filtering, block senders, multiple identities, options to read/send text 
> only, various encoding options, options for composing, signatures, etc. 
> Import/export address books, etc.
>
> I think you're just being a cola moron so you can fit in.

Not at all.  I've completely stopped using Outlook.  Even Microsoft
webmail is better.

> Without doing too much research, it seems Windows (2000 anyway) has tools to 
> get core dumps
>
> http://labmice.techtarget.com/troubleshooting/memorydumps.htm

Cool!

-- 
   "I'm going to f'in *kill* Google!"
     -- Steve Ballmer, CEO Microsoft

In comp.os.linux.advocacy, John Bailo
<jabailo@texeme.com>
 wrote
on Mon, 10 Jul 2006 15:40:22 -0700
<2pudnQSYiMHJSi_ZnZ2dnUVZ_oudnZ2d@speakeasy.net>:
> DFS wrote:
>
>>  And it figures a biased, anti-MS ignoramus like you wouldn't 
>> know that you can write multi-threaded Visual Basic apps.
>
> That's only really been true since VB.NET
>
> Yes, there was a Thread object in VB6 and you could use the Timer in 
> thread-line ways...but it was still almost impossible.
>
> Also, VB.NET is still has single class inheritance.

So does Java.  Doesn't seem to have hurt them any. ;-)

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.

In comp.os.linux.advocacy, I've Got Gregorius!
<jabailo@texeme.com>
 wrote
on Mon, 10 Jul 2006 19:33:28 -0700
<7o-dnaEFbuRlkC7ZnZ2dnUVZ_q-dnZ2d@speakeasy.net>:
> Ginsu Warrior wrote:
>
>> Notice how all the cola nuts cry and complain about windows but when it
>> comes to work and making a living they all write Windows code for a
>> living.
>
> Most write .Net (VB, c) code and java for a living.
>
> Both of those are cross platform for Linux and Windows.
>
> And if they weren't -- they would never have taken off...
>

Correct.  If it doesn't run on Windows, apparently, it
doesn't go anywhere.

There are exceptions, of course.  Mainframe servers
routinely run a mix of things -- nowadays, mostly Unix.
Considering that Unix was originally designed for PDP 11
minicomputers -- or even older -- Unix is an impressive
achievement.  Considering that Microsoft is by far the
largest and most profitable software company in the world
($237B market cap, $42.64B revenues, $13.47 income),
surpassing Lucent Technologies ($10.09B, $8.96B, $0.821B)
-- AIUI, that's the Bell Labs spinoff from AT&T ($106.34B,
$49.45B, $5.35B) -- it's somewhat less so; Microsoft is
the clear winner here.

Google ($126.82B, $7.41B, $1.69B) might be a threat,
but its revenues are currently anemic in comparison.
IBM ($117.55B, $88.89B, $8.30B) has better revenues than
Google, but lower margins; hardware is like that. :-)

(For its part, Yahoo!, which runs the finance page from
which I'm getting all these figures, weighs in at
($46.10B, $5.65B, $1.85B).  Not a peewee, but Google has
3x the worth on about 1.3x the revenue and less profit.
Go figure.)

Even Halliburton, one of the bigger players in the Bush
Administration and a prominent oil and gas producer and
equipment maker, can't match these numbers, and in fact
is almost an order of magnitude lower in profits, though
they get half the revenue.  ($37.78B, $21.44B, $2.48B)
Of course part of that is the inherent difference in
business; oil and gas inherently has less margin.

Makes me wonder not so much regarding Microsoft's
machinations, but at ourselves.

Part of the problem is that for the vast majority, Microsoft
is the window (and the Windows) to the Internet world.
It's the first thing people see on their desktop, and
if Microsoft had their way it would be the first thing
people see on cell phones, media centers (TV with a 'tude),
the Internet (MSN), and other venues as well.

(For its part, Netscape AIUI is held by Time Warner
($69.93B, $43.74B, $3.20B for TWX, $1.61B, $0.72334B,
-$0.09516B for TWTC, no reading on UYE).  There's
also Apple ($47.03B, $17.31B, $1.73B) and Intel
($105.35B, $38.33B, $7.84B).)

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.

Ginsu Warrior wrote:

> Notice how all the cola nuts cry and complain about windows but when it
> comes to work and making a living they all write Windows code for a
> living.
> 

Personally, I write generic code, where the initial release is under
Windows. 

Ian

In comp.os.linux.advocacy, Ian Hilliard
<nospam@hilliardtech.com>
 wrote
on Tue, 11 Jul 2006 22:59:04 +0200
<cbba9$44b4110e$544a537b$2198@news.hispeed.ch>:
> Ginsu Warrior wrote:
>
>> Notice how all the cola nuts cry and complain about windows but when it
>> comes to work and making a living they all write Windows code for a
>> living.
>> 
>
> Personally, I write generic code, where the initial release is under
> Windows. 
>
> Ian

An interesting use of linguistics.  How "generic" is
generic under Windows?  The best I can come up with is
the more or less usual layer cake:

- os-dependent service stuff, which can be swapped out
- generic mid-level processing
- generic high-level presentation
- env-dependent GUI stuff, which can be swapped out

Say what one will about Windows, it at least has generic
concepts when it comes to such things as files, text,
and such.  Apple's resource fork has apparently gone by
the wayside, but was used by a lot of MacOS programs prior
to version 10.  Amiga's ".info" files were fairly stock.

Gnome (actually, nautilus) now has .desktop files if one
needs custom launchers, and otherwise displays icons in
interesting ways.  The .desktop files are little more than
property lists, one property per text line.

And of course POSIX makes for very generic code,
standardizing things like open() and C++ libraries.

So kudos for using generic code, but I'll admit with
Windows one has to ask such questions, since Windows is
generic enough -- but nowhere near standard.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.

The Ghost In The Machine wrote:

> An interesting use of linguistics.  How "generic" is
> generic under Windows?  The best I can come up with is
> the more or less usual layer cake:
> 
> - os-dependent service stuff, which can be swapped out
> - generic mid-level processing
> - generic high-level presentation
> - env-dependent GUI stuff, which can be swapped out
> 

This is almost right;

- os-dependent service stuff, which can be swapped out.
  There currently exists three version of this core library,
  one for Solaris, one for Windows and one for Linux. The API's are the same
  for all three and follow standard object patterns. Thread, Mutex, File,
  Socket, ManagedObjectPool, ConfigurationFile, etc...

- generic mid-level processing

- generic high level presentation and messaging. Messages are passed between
the interface and the application. As such, the core application can be a
service or daemon. The API starts very quickly and the application is
immediately ready to rumble. Where necessary and more grunt is required the
core application can reside on a more powerful machine such as a large
multi-processor Sun server or a Linux cluster.

- GUI with interface to messaging system. This can be written with any tool
kit you want. I quite like wxWidgets for this sort of a task.

Apart from the OS abstraction layer and the GUI, ALL code must be ANSI
compliant and coded in such a manor that anybody could easily take it over.

The mid-level stuff uses a lot of standard patterns for real-time, such as
object pools and state patterns.

Ian

DFS wrote:

> (as far as 99.999% reliability, that requirement had to have been dropped
> a long time ago - if the program crashes and is down for more than 5.25
> minutes).
> 

The 99.999% reliability is a hard requirement. There is no getting around
it. This is why it is so critical that we find everything that could
possibly kill the application, even if it is a race condition that occurs
maybe once a week, with the application running 24/7 at 150% load.

To that, we have a system of hot standbys and load sharing. With Windows
it's hard, but I think we will be able to meet it.

Ian

In comp.os.linux.advocacy, Ian Hilliard
<nospam@hilliardtech.com>
 wrote
on Wed, 12 Jul 2006 20:00:20 +0200
<45746$44b538a7$544a537b$20884@news.hispeed.ch>:
> The Ghost In The Machine wrote:
>
>> An interesting use of linguistics. �How "generic" is
>> generic under Windows? �The best I can come up with is
>> the more or less usual layer cake:
>> 
>> - os-dependent service stuff, which can be swapped out
>> - generic mid-level processing
>> - generic high-level presentation
>> - env-dependent GUI stuff, which can be swapped out
>> 
>
> This is almost right;
>
> - os-dependent service stuff, which can be swapped out.
>   There currently exists three version of this core library,
>   one for Solaris, one for Windows and one for Linux. The API's are the same
>   for all three and follow standard object patterns. Thread, Mutex, File,
>   Socket, ManagedObjectPool, ConfigurationFile, etc...
>
> - generic mid-level processing
>
> - generic high level presentation and messaging. Messages are passed between
> the interface and the application. As such, the core application can be a
> service or daemon. The API starts very quickly and the application is
> immediately ready to rumble. Where necessary and more grunt is required the
> core application can reside on a more powerful machine such as a large
> multi-processor Sun server or a Linux cluster.
>
> - GUI with interface to messaging system. This can be written with any tool
> kit you want. I quite like wxWidgets for this sort of a task.

I've not played with wxWidgets much but that's presumably
a choice that could work for Windows as well as any Unix
or Unix-like OS.

>
> Apart from the OS abstraction layer and the GUI, ALL code must be ANSI
> compliant and coded in such a manor that anybody could easily take it over.
                                ^
>
> The mid-level stuff uses a lot of standard patterns for real-time, such as
> object pools and state patterns.

Kewl.  But do you really have to code on an estate? :-)

>
> Ian
>

-- 
#191, ewill3@earthlink.net -- insert random house here
Windows Vista.  Because it's time to refresh your hardware.  Trust us.

The Ghost In The Machine wrote:

> I've not played with wxWidgets much but that's presumably
> a choice that could work for Windows as well as any Unix
> or Unix-like OS.
> 

Their basically MFC on steroids but without the bugs. The thing that is
still really missing is a tool to graphically create the interfaces. In
many cases it is faster to create the interface using Visual Studio and
then port to wxWidgets. 

I like using them, but I do have a bit of a gripe. If GTK is on the machine,
wxWidgets uses it. This makes it GPL under Linux. The companies I work for
have no interest in releasing their sources. As such, it is very hard to
convince management to move to Linux for anything but low-level commodity
type operations. Such a thing is a redirector of datagrams to multiple
addresses without modifying the original source detail, by using linux raw
sockets.

Ian

In comp.os.linux.advocacy, Ian Hilliard
<nospam@hilliardtech.com>
 wrote
on Wed, 12 Jul 2006 21:55:07 +0200
<e7d47$44b5538e$544a537b$3512@news.hispeed.ch>:
> The Ghost In The Machine wrote:
>
>> I've not played with wxWidgets much but that's presumably
>> a choice that could work for Windows as well as any Unix
>> or Unix-like OS.
>> 
>
> Their basically MFC on steroids but without the bugs. The thing that is
> still really missing is a tool to graphically create the interfaces. In
> many cases it is faster to create the interface using Visual Studio and
> then port to wxWidgets. 
>
> I like using them, but I do have a bit of a gripe. If GTK is on the machine,
> wxWidgets uses it. This makes it GPL under Linux. The companies I work for
> have no interest in releasing their sources. As such, it is very hard to
> convince management to move to Linux for anything but low-level commodity
> type operations. Such a thing is a redirector of datagrams to multiple
> addresses without modifying the original source detail, by using linux raw
> sockets.
>
> Ian

Hm.  Two questions.

[1] Has this ever been tested in court?

[2] Presumably, someone could go in there and hack wxWidgets so as to
*not* use GTK when on a machine.  Either that, or shut off a build
dependency.

I'll admit to some curiosity.  libreadline in particular
is a GPL (*not* LGPL) library, and the term "derived
work" figures prominently in the license.  Would it be
weird to claim that any command/shell processor using the
libreadline utility routines is a "derived work"?

That's one rather obvious place where FUD could seep in
and ruin the woodwork, methinks.  :-)  (It's certainly
warped my brain. :-) )

(gentoo's /usr/portage isn't too illuminating; the "use flags" for
wxGTK are "X gnome opengl sdl unicode debug doc joystick odbc".)

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.