7 ms·

>> This problem has been reported when querying an ORACLE 7.3 data source by using the following ODBC drivers. Sqo32_73.dll is manufactured by Oracle Corporatio

by tszming 13y ago

>> This problem has been reported when querying an ORACLE 7.3 data source by using the following ODBC drivers. Sqo32_73.dll is manufactured by Oracle Corporation. Microsoft makes no warranty, implied or otherwise, regarding this product's performance or reliability. Maybe not the fault of Microsoft?

foobarian 13y ago
I'm always fascinated by how tightly bound various software is with UI code in Windows. It's the equivalent of random shell scripts having Xlib or Gnome dependencies just to show a progress meter. I guess if it's an event loop thing one could also alternate 'z' and 'x' as fast as possible :-)
- weland 13y ago
  This was a major culture clash for me when I ended up working at a company that mainly sells Windows software. I do my best to stay objective about it and not jump to the conclusion that it's incredibly broken because of its hairiness.
  - Joeri 13y ago
    Microsoft agrees that it's broken, which is why they're trying to get rid of the windows desktop and its legacy API's.
    - asveikau 13y ago
      I think you are jumping to too many conclusions here, or maybe just not being precise about what "it" refers to. It may surprise you that it will still be possible to write poorly coupled code and create bugs with the WinRT APIs.
      - vidarh 13y ago
        It's possible to do that for any system. My distaste for Microsoft is deep, but the ability to write crappy software does not say anything about Windows itself.
- crazygringo 13y ago
  In your experience, is OSX or Linux graphical software any better? Genuinely curious. I feel like interface freezes happen on all major platforms, and always assumed it had more to do with the applications than with the platforms. I mean, writing interfaces that never block is a lot more work. But I don't have a lot of cross-platform experience to know if some platforms make it easier than others.
  - vidarh 13y ago
    Yes, it has more to do with being able to usually get away with methods that really belong in the trash. My "first love" in OS's is AmigaOS, and while the OS is very dated in many ways (no memory protection, no SMP support), one of the things it really got right was to encourage extremely extensive multithreading. On Amiga's it was a necessity if you wanted to have full multitasking, as the machines were slow enough and memory constrained enough that not doing it would severely limit usability (frankly, it would have done PC's a world of good too, but the PC world took the simpler approach of not even trying for proper multi-tasking). My favourite example is how cut and paste from the console worked. It includes the device handlers handling keyboard and mouse input, the intuition input handler, which processes the raw input events and turns them into input events for specific windows, the console.device device handler which takes intuition events for console windows and "cooks" the events into higher level events that gets passed to the console-handler, which then will find the area you are selecting, and call a function that passes the buffer to the clipboard.device, which will then create a clipboard entry that gets written to a disk volume, which involves the filesystem handler for that filesystem, which again likely will involve a device suck as ram.device or trackdisk.device to write it to the actual device. Every single one of these steps is handled by a separate thread/process (the distinction doesn't mean much on AmigaOS due to the lack of memory protection, and are usually referred to as "task" instead). The reason for this is all down to responsiveness: The input devices and things like trackdisk.device musc deal with hardware, and so must have priority. But if the rest of the flow was given high priority, the system would be sluggish, so the minimum amount of work is done, put into a message, tacked onto a queue, and things are off to a start. At the opposite end, things like clipboard.device must not lock up when clipboard entries are added, as while the clipboards are usually in RAM:, they are files on a filesystem, and a user with only 512KB RAM and possibly no harddrive might in fact be using a floppy drive for the clipboard - forcing the user to wait for a floppy write would have been intolerable (and why Amiga users loved to mock Windows 3.x users back in the day). This permeated through many applications as well. It was a matter of pride for many developers, and the first chapters in many Amiga developer books tended to involve Exec (Amiga's "kernel", or parts of it) which provided a set of library functions for managing messages, lists of messages and message ports, as they were essential for talking to the OS, but also readily available for application developers. For many, before you'd written your first "hello world" app you had gotten a crash course in making things asynchronous by default. Today a day go by for me without either my browser freezing, or Thunderbird freezing or some other application, both on Linux at home and OS X at work. And on the few occasions I've had to work on Windows machines, there too. Every time it happens, I dream wistfully about a world where people understood how to write software that way. It is, in fact, not all that hard: "All it takes" is to subdivide your application into smaller components that only communicate using async message queues. Incidentally it makes the apps easier to test too, and easier to make robust (unlike under AmigaOS, on a modern OS you can separate components on process boundaries where it makes sense too, and automatically restart failed components), and it makes it easy to make them scriptable etc.
deleted 13y ago
[deleted]
lisper 13y ago
Microsoft designed and built the OS and two of the three applications involved. And the third application was almost certainly built using Microsoft development tools according to Microsoft guidelines. How could this not be their fault?
- zbowling 13y ago
  Just because they give you a C compiler and a library to link doesn't mean you blame the compiler developer for letting the user shoot himself in the foot.
  - lisper 13y ago
    That's true, but it's a straw-man argument, because Microsoft did not just produce the compiler. They produced the compiler AND the operating system AND two of the three applications in question.
  - weland 13y ago
    If I understood it correctly, the problem isn't that Oracle is using the Microsoft libraries and compilers incorrectly, it's the other way around. The two applications that are broken when using Oracle's ODBC drivers are actually Microsoft's, so it superficially looks like the company with the user-facing problems either doesn't want to fix their bugs or doesn't want to work around the bugs in the ODBC driver. This isn't too uncommon, actually, but what usually happens is that the company with the upper hand prevails and the other one has to fix the bugs, lest they piss off their customers who have to leave. However, when both companies keep their users in tight vendor lockdowns, they just wave their cocks around for a few months blaming each other and settle for the users working around, since it's the cheapest alternative.
- asveikau 13y ago
  When I acquire a mutex inside my callback, it deadlocks. Microsoft wrote the calling function and the mutex implementation! Stupid Microsoft! Never mind that my callback violated the caller's threading model and that mutices introduce deadlocks when used incorrectly... They should fix the bug! Edit: I guess what I was trying to say is that this part needs a huge "citation needed": > was almost certainly built ... according to Microsoft guidelines We don't know that at all. When you insert your code into another process, bugs in your code have the potential to destabilize that process. This discussion is extremely light on details but we cannot assume that the caller, rather than the callee, is at fault. If it's working correctly with another driver, I say, look at the suspicious driver, it's likely got a bug.

by tszming 13y ago

foobarian 13y ago

I'm always fascinated by how tightly bound various software is with UI code in Windows. It's the equivalent of random shell scripts having Xlib or Gnome dependencies just to show a progress meter. I guess if it's an event loop thing one could also alternate 'z' and 'x' as fast as possible :-)

weland 13y ago
This was a major culture clash for me when I ended up working at a company that mainly sells Windows software. I do my best to stay objective about it and not jump to the conclusion that it's incredibly broken because of its hairiness.
- Joeri 13y ago
  Microsoft agrees that it's broken, which is why they're trying to get rid of the windows desktop and its legacy API's.
  - asveikau 13y ago
    I think you are jumping to too many conclusions here, or maybe just not being precise about what "it" refers to. It may surprise you that it will still be possible to write poorly coupled code and create bugs with the WinRT APIs.
    - vidarh 13y ago
      It's possible to do that for any system. My distaste for Microsoft is deep, but the ability to write crappy software does not say anything about Windows itself.
crazygringo 13y ago
In your experience, is OSX or Linux graphical software any better? Genuinely curious. I feel like interface freezes happen on all major platforms, and always assumed it had more to do with the applications than with the platforms. I mean, writing interfaces that never block is a lot more work. But I don't have a lot of cross-platform experience to know if some platforms make it easier than others.
- vidarh 13y ago
  Yes, it has more to do with being able to usually get away with methods that really belong in the trash. My "first love" in OS's is AmigaOS, and while the OS is very dated in many ways (no memory protection, no SMP support), one of the things it really got right was to encourage extremely extensive multithreading. On Amiga's it was a necessity if you wanted to have full multitasking, as the machines were slow enough and memory constrained enough that not doing it would severely limit usability (frankly, it would have done PC's a world of good too, but the PC world took the simpler approach of not even trying for proper multi-tasking). My favourite example is how cut and paste from the console worked. It includes the device handlers handling keyboard and mouse input, the intuition input handler, which processes the raw input events and turns them into input events for specific windows, the console.device device handler which takes intuition events for console windows and "cooks" the events into higher level events that gets passed to the console-handler, which then will find the area you are selecting, and call a function that passes the buffer to the clipboard.device, which will then create a clipboard entry that gets written to a disk volume, which involves the filesystem handler for that filesystem, which again likely will involve a device suck as ram.device or trackdisk.device to write it to the actual device. Every single one of these steps is handled by a separate thread/process (the distinction doesn't mean much on AmigaOS due to the lack of memory protection, and are usually referred to as "task" instead). The reason for this is all down to responsiveness: The input devices and things like trackdisk.device musc deal with hardware, and so must have priority. But if the rest of the flow was given high priority, the system would be sluggish, so the minimum amount of work is done, put into a message, tacked onto a queue, and things are off to a start. At the opposite end, things like clipboard.device must not lock up when clipboard entries are added, as while the clipboards are usually in RAM:, they are files on a filesystem, and a user with only 512KB RAM and possibly no harddrive might in fact be using a floppy drive for the clipboard - forcing the user to wait for a floppy write would have been intolerable (and why Amiga users loved to mock Windows 3.x users back in the day). This permeated through many applications as well. It was a matter of pride for many developers, and the first chapters in many Amiga developer books tended to involve Exec (Amiga's "kernel", or parts of it) which provided a set of library functions for managing messages, lists of messages and message ports, as they were essential for talking to the OS, but also readily available for application developers. For many, before you'd written your first "hello world" app you had gotten a crash course in making things asynchronous by default. Today a day go by for me without either my browser freezing, or Thunderbird freezing or some other application, both on Linux at home and OS X at work. And on the few occasions I've had to work on Windows machines, there too. Every time it happens, I dream wistfully about a world where people understood how to write software that way. It is, in fact, not all that hard: "All it takes" is to subdivide your application into smaller components that only communicate using async message queues. Incidentally it makes the apps easier to test too, and easier to make robust (unlike under AmigaOS, on a modern OS you can separate components on process boundaries where it makes sense too, and automatically restart failed components), and it makes it easy to make them scriptable etc.

deleted 13y ago

[deleted]

lisper 13y ago

Microsoft designed and built the OS and two of the three applications involved. And the third application was almost certainly built using Microsoft development tools according to Microsoft guidelines. How could this not be their fault?

zbowling 13y ago
Just because they give you a C compiler and a library to link doesn't mean you blame the compiler developer for letting the user shoot himself in the foot.
- lisper 13y ago
  That's true, but it's a straw-man argument, because Microsoft did not just produce the compiler. They produced the compiler AND the operating system AND two of the three applications in question.
- weland 13y ago
  If I understood it correctly, the problem isn't that Oracle is using the Microsoft libraries and compilers incorrectly, it's the other way around. The two applications that are broken when using Oracle's ODBC drivers are actually Microsoft's, so it superficially looks like the company with the user-facing problems either doesn't want to fix their bugs or doesn't want to work around the bugs in the ODBC driver. This isn't too uncommon, actually, but what usually happens is that the company with the upper hand prevails and the other one has to fix the bugs, lest they piss off their customers who have to leave. However, when both companies keep their users in tight vendor lockdowns, they just wave their cocks around for a few months blaming each other and settle for the users working around, since it's the cheapest alternative.
asveikau 13y ago
When I acquire a mutex inside my callback, it deadlocks. Microsoft wrote the calling function and the mutex implementation! Stupid Microsoft! Never mind that my callback violated the caller's threading model and that mutices introduce deadlocks when used incorrectly... They should fix the bug! Edit: I guess what I was trying to say is that this part needs a huge "citation needed": > was almost certainly built ... according to Microsoft guidelines We don't know that at all. When you insert your code into another process, bugs in your code have the potential to destabilize that process. This discussion is extremely light on details but we cannot assume that the caller, rather than the callee, is at fault. If it's working correctly with another driver, I say, look at the suspicious driver, it's likely got a bug.