"So because Wine is only known to work with many Windows applications and not *all* Windows applications, it's not suitable to use for any Windows applications?"
As you well know, that's not what I said. I think it makes sense to say Wine allows you run Windows applications x,y, and z. It doesn't make sense to claim it's a general replacement for Windows.
I don't know the details because I have no interest in it. Given it's unfinished state, it seems inappropriate that it is recommended so often as a viable alternative to using Windows.
"So they were more places where ill-advised maintenance might well have introduced a bug in the future."
That was exactly my point in a previous post. There are a million ways that "ill-advised maintenance" can insert bugs, so it's not clear if analyzing and potentially modifying code based on one of these automated scans is an effective use of scarce programming resources. Each code modification is also an opportunity to insert a bug as well.
God forbid that anyone would have to recognize a problem without the help of the compiler, or write a test case outside the comfortable confines of the unit testing frameworks that are currently in vogue.
The real problem with the code you used an example is that the programmer who changed the first line did so without adequately studying the existing code. Future bug insertion can't be prevented by anyone except the individual guilty of it.
A bug is something that causes a program to work incorrectly. It has nothing to do with mistakes that may be made later in other software releases.
"That does not mean all found points are truely positive, but thy definitely are bad coding practice and my end in a bug later if the code gets changed."
All changes to code have the potential to introduce a bug. Sorry, but non-conformance with "best practices" is not a bug.
This is the problem with a lack of formal requirements. If the requirement is to run all Windows applications properly, than not doing it is a bug. If the requirement is to run a specific subset of Windows applications, than it's not.
Of course, if the problem is that Wine is not finished, than it should be label as a work in progress rather than a finished product.
I'd say even the most self-indulgent programmer is going to lose interest in a company it they know their work will never see the light of day:
Guy 1: Where do you work? Google Guy: At Google. Guy 1: Wow, that's impressive. Which application did you work on? Search? Gmail? Google Guy: I worked on something that they decided not release. Guy 1: Oh, that's too bad.
I agree that it's generally not a good idea to bypass the OS, but that doesn't mean it can't be done. We're not talking about best practices here, were talking about protecting against malicious programs.
The processor was a 6507 which is a 6502 with fewer pins. I don't remember how many registers it has (I haven't used it for over 20 years after all). The Atari 2600 not only didn't have an OS, it didn't have any software in it at all. All the software was in the game cartridge. The system had no interupts although it did have a timer you could poll. There was no 2 dimensional video buffer, just registers that had to be reloaded each scan line if you wanted the data to change. The effect of vertical movement was achieved by controlling the data in the registers. Horizontal movement was achieved by writing to positioning registers, but not with a x value, rather how much time had elipsed between the start of a scan line and the time you write to the positioning register. In other words, if you wanted the object to appear at the middle of the screen you'd write to the register 76/2 CPU cycles after the start of a scan line (there are 76 cpu cycles per scan line). There was a register you could write to that would hold the processor up until the scan line started so you could sync up. In high performance games you'd do this as infrequency as possible because it used up 3 precious CPU cycles that you might need for changing color or reloading a register. The were only 2 high resolution "objects" (sometimes called players), 2 "bullets" (sometimes called missles) and 3 very blocky background objects. Because of this there were a number of register reuse schemes. Games would look a lot better if you understood the limitations of the system and took advantage of them. For example, many Activision games (The very first Atari programmers started that company after leaving Atari) would divide the screen into levels with one "bad guy" staying on each level and the "hero" controlled by the gamer moving freely to any level. The reason for this design was to insure that only 2 high-resolution objects were on the same scan line at the same time. On the other hand, a game like PacMan violates this rule and thus the objects have to be multiplexed ("ghosted") to make the gameplay work. That's why the Atari 2600 version of PacMan sucked so much.
No, an application doesn't have to go throught the OS to get to the memory or hardware unless there is hardware there it enforce it and the OS has programmed it properly.
You seem to have trouble deciding whether I'm a young guy that should be asking my Dad for help or an old guy who has obsolete ideas about how programs are written (Since my father was born before the vacuum tube was invented, I don't think he would be much help.)
"Do you really think things are still done by each application choosing an explicit range of memory addresses itself like you have on systems without an operation system instead of asking the OS to give it memory as happens on systems with an operating system?"
What makes you think that somebody who wants to write a malicious program is going to play by your rules. Asking the OS for memory is cooperative strategy, playing well with others isn't the goal of hacking.
Sure, you can make an OS that doesn't allow programs written in native code to run, but it's not very useful.
Also keep in mind that the context of this discussion is whether MS should have been able to create a secure OS given the platform it started with (i.e. 8088 processor etc). The idea that such an emulator could fit within that environment and still have room for anything else is unrealistic at best.
Slashdot Mirror
"For years I refused to buy off the shelf equipment because ME was the only option."
There was never a time when Windows ME was the only version of Windows on sale.
"So because Wine is only known to work with many Windows applications and not *all* Windows applications, it's not suitable to use for any Windows applications?"
As you well know, that's not what I said. I think it makes sense to say Wine allows you run Windows applications x,y, and z. It doesn't make sense to claim it's a general replacement for Windows.
I don't know the details because I have no interest in it. Given it's unfinished state, it seems inappropriate that it is recommended so often as a viable alternative to using Windows.
"So they were more places where ill-advised maintenance might well have introduced a bug in the future."
That was exactly my point in a previous post. There are a million ways that "ill-advised maintenance" can insert bugs, so it's not clear if analyzing and potentially modifying code based on one of these automated scans is an effective use of scarce programming resources. Each code modification is also an opportunity to insert a bug as well.
God forbid that anyone would have to recognize a problem without the help of the compiler, or write a test case outside the comfortable confines of the unit testing frameworks that are currently in vogue.
The real problem with the code you used an example is that the programmer who changed the first line did so without adequately studying the existing code. Future bug insertion can't be prevented by anyone except the individual guilty of it.
A bug is something that causes a program to work incorrectly. It has nothing to do with mistakes that may be made later in other software releases.
Almost any video game created during the "classic" period.
"That does not mean all found points are truely positive, but thy definitely are bad coding practice and my end in a bug later if the code gets changed."
All changes to code have the potential to introduce a bug. Sorry, but non-conformance with "best practices" is not a bug.
This is the problem with a lack of formal requirements. If the requirement is to run all Windows applications properly, than not doing it is a bug. If the requirement is to run a specific subset of Windows applications, than it's not.
Of course, if the problem is that Wine is not finished, than it should be label as a work in progress rather than a finished product.
Opportunity-> 0
Camera Mast Shadow-> .
I'd say even the most self-indulgent programmer is going to lose interest in a company it they know their work will never see the light of day:
Guy 1: Where do you work?
Google Guy: At Google.
Guy 1: Wow, that's impressive. Which application did you work on? Search? Gmail?
Google Guy: I worked on something that they decided not release.
Guy 1: Oh, that's too bad.
That wouldn't surprise me a bit. The last thing you want when you believe you're God's gift is to have people around that undermine that belief.
"cut back on the volume of products being offered"
Didn't we learn last week that you can work on anything you want at Google?
What do you want to bet that the programmers at YouTube would have never made it through Google's interview process?
When I was a kid I played video games at least .. Oh wait, there were no video games when I was a kid.
"Do you remember Active Desktop and Push technology"
No, but that's the point isn't it.
If you even heard of html when you were young, you're still young.
I'd say Ann Coulter is way beyond being a simple neo-con, more like a neo-conehead.
No telepathy required, just a schematic.
I agree that it's generally not a good idea to bypass the OS, but that doesn't mean it can't be done. We're not talking about best practices here, were talking about protecting against malicious programs.
I'll humor you and give you a partial dump:
The processor was a 6507 which is a 6502 with fewer pins. I don't remember how many registers it has (I haven't used it for over 20 years after all). The Atari 2600 not only didn't have an OS, it didn't have any software in it at all. All the software was in the game cartridge. The system had no interupts although it did have a timer you could poll. There was no 2 dimensional video buffer, just registers that had to be reloaded each scan line if you wanted the data to change. The effect of vertical movement was achieved by controlling the data in the registers. Horizontal movement was achieved by writing to positioning registers, but not with a x value, rather how much time had elipsed between the start of a scan line and the time you write to the positioning register. In other words, if you wanted the object to appear at the middle of the screen you'd write to the register 76/2 CPU cycles after the start of a scan line (there are 76 cpu cycles per scan line). There was a register you could write to that would hold the processor up until the scan line started so you could sync up. In high performance games you'd do this as infrequency as possible because it used up 3 precious CPU cycles that you might need for changing color or reloading a register. The were only 2 high resolution "objects" (sometimes called players), 2 "bullets" (sometimes called missles) and 3 very blocky background objects. Because of this there were a number of register reuse schemes. Games would look a lot better if you understood the limitations of the system and took advantage of them. For example, many Activision games (The very first Atari programmers started that company after leaving Atari) would divide the screen into levels with one "bad guy" staying on each level and the "hero" controlled by the gamer moving freely to any level. The reason for this design was to insure that only 2 high-resolution objects were on the same scan line at the same time. On the other hand, a game like PacMan violates this rule and thus the objects have to be multiplexed ("ghosted") to make the gameplay work. That's why the Atari 2600 version of PacMan sucked so much.
I think I've probably bored you enough.
Actually, my video game experience doesn't extend beyond the Atari 2600 which I programmed professionaly.
No, an application doesn't have to go throught the OS to get to the memory or hardware unless there is hardware there it enforce it and the OS has programmed it properly.
You seem to have trouble deciding whether I'm a young guy that should be asking my Dad for help or an old guy who has obsolete ideas about how programs are written (Since my father was born before the vacuum tube was invented, I don't think he would be much help.)
"Do you really think things are still done by each application choosing an explicit range of memory addresses itself like you have on systems without an operation system instead of asking the OS to give it memory as happens on systems with an operating system?"
What makes you think that somebody who wants to write a malicious program is going to play by your rules. Asking the OS for memory is cooperative strategy, playing well with others isn't the goal of hacking.
Sure, you can make an OS that doesn't allow programs written in native code to run, but it's not very useful.
Also keep in mind that the context of this discussion is whether MS should have been able to create a secure OS given the platform it started with (i.e. 8088 processor etc). The idea that such an emulator could fit within that environment and still have room for anything else is unrealistic at best.
Yes, I know you don't have a counter-argument, but it's OK. You can insult me if it makes you feel better.