Some of the more interesting bugs are the ones not in your code.
I decided to list the ones outside my code that I've found in the last year or so. These are windows / .net bugs.
1. When you add a program to run at startup to the registry and that program has a space in it. Like this "CoolCompany CoolSoftware.exe" it will also launch the program in the same directory called "CoolCompany ReallyCoolSoftware.exe"
2. The FILETIME data type in .net is mis-defined as signed. This leads to conversion problems that were really hard to track down. File times would magically change in certain conditions by a few seconds to a few minutes. This was still in the 3.0 version which is the last I checked.
3. .net Socket library pins the buffer in memory to prevent garbage collection and allow the call to not lose the buffer. Unfortunately it never unpins the memory. This looks like a memory leak and fragments the heap badly.
4. The split control width is reported differently on XP and Vista. Hiding the split on one platform will give a width of zero. On the other one it reports the width.
5. The zip lib on .net CLR ends up with much worse compression than a properly implemented zip lib. Ironically the J# zip lib works well.
6. The windows setup in visual studio release build fails to install required components like .net. The debug build will?
7. The .net file and directory objects don't support long paths. A user can easily create a path longer than the limit by dragging another user's directory to their desktop. These files will (un)conveniently be unreachable by any .net app not making direct win32 calls.
8. I don't even want to think about the threading model in .net with delegates (they don't always work) etc. Bonus they work differently on Vista yea! Give me a semaphore, a mutex, etc.
9. Vista UAC is such an embarrassment. I'm completely astonished it got released. In my opinion everyone who even saw it should be fired. The design is worse than privilege elevation designed over a quarter century earlier. The implementation is so bad any still sane person that uses their computer for more than light work will turn it off.
Windows aside. If anyone is developing a commercial app on windows. I strongly recommend writing directly to the win32 API. If you try to implement anything non-trivial (like I did) you may end up with a huge rewrite. In my opinion the convenience of .net is just not worth the loss of control.
I'm in mid port to a native code version of my application. I've lost 95% of the re-distributable size and increased performance by 50%.
Seriously though. I think there is a general problem with programming.
Part of the problem is the workaround. There is a certain amount pride / respect someone gets for figuring out a work around to a tough problem. The issue with this is that it discourages the fixing of the root problem.
The other part of the problem is consistency. "I don't care what the interface is as long as it is concise and consistent." I often feel like a turn of the century mechanic trying to build a car from a box of randomly sourced parts. At the turn of the century there were not any standards for important things like bolts. Everything varied from thread width to thread angle to thread spacing. The situation with non standard mechanical parts is pretty close to what we have today with software. Sometimes I think all I do is write code to convert data from one type to another. All to appease the requirements of the various APIs I need to use.
Someone will probably note that I'm on windows and X is so much better to code to. I will prematurely completely agree. I typically hack on my mac and my grid runs on linux boxes. I need a windows component for market reasons.
Bonus!!! The Unknown or expired link when posting to Hacker News after typing for a long time.
I decided to list the ones outside my code that I've found in the last year or so. These are windows / .net bugs.
1. When you add a program to run at startup to the registry and that program has a space in it. Like this "CoolCompany CoolSoftware.exe" it will also launch the program in the same directory called "CoolCompany ReallyCoolSoftware.exe"
2. The FILETIME data type in .net is mis-defined as signed. This leads to conversion problems that were really hard to track down. File times would magically change in certain conditions by a few seconds to a few minutes. This was still in the 3.0 version which is the last I checked.
3. .net Socket library pins the buffer in memory to prevent garbage collection and allow the call to not lose the buffer. Unfortunately it never unpins the memory. This looks like a memory leak and fragments the heap badly.
4. The split control width is reported differently on XP and Vista. Hiding the split on one platform will give a width of zero. On the other one it reports the width.
5. The zip lib on .net CLR ends up with much worse compression than a properly implemented zip lib. Ironically the J# zip lib works well.
6. The windows setup in visual studio release build fails to install required components like .net. The debug build will?
7. The .net file and directory objects don't support long paths. A user can easily create a path longer than the limit by dragging another user's directory to their desktop. These files will (un)conveniently be unreachable by any .net app not making direct win32 calls.
8. I don't even want to think about the threading model in .net with delegates (they don't always work) etc. Bonus they work differently on Vista yea! Give me a semaphore, a mutex, etc.
9. Vista UAC is such an embarrassment. I'm completely astonished it got released. In my opinion everyone who even saw it should be fired. The design is worse than privilege elevation designed over a quarter century earlier. The implementation is so bad any still sane person that uses their computer for more than light work will turn it off.
Windows aside. If anyone is developing a commercial app on windows. I strongly recommend writing directly to the win32 API. If you try to implement anything non-trivial (like I did) you may end up with a huge rewrite. In my opinion the convenience of .net is just not worth the loss of control.
I'm in mid port to a native code version of my application. I've lost 95% of the re-distributable size and increased performance by 50%.
Seriously though. I think there is a general problem with programming.
Part of the problem is the workaround. There is a certain amount pride / respect someone gets for figuring out a work around to a tough problem. The issue with this is that it discourages the fixing of the root problem.
The other part of the problem is consistency. "I don't care what the interface is as long as it is concise and consistent." I often feel like a turn of the century mechanic trying to build a car from a box of randomly sourced parts. At the turn of the century there were not any standards for important things like bolts. Everything varied from thread width to thread angle to thread spacing. The situation with non standard mechanical parts is pretty close to what we have today with software. Sometimes I think all I do is write code to convert data from one type to another. All to appease the requirements of the various APIs I need to use.
Someone will probably note that I'm on windows and X is so much better to code to. I will prematurely completely agree. I typically hack on my mac and my grid runs on linux boxes. I need a windows component for market reasons.
Bonus!!! The Unknown or expired link when posting to Hacker News after typing for a long time.