MS already does this, with HTML^H^H^H^Hrubbish that gets spat out from Word2k, when you do a "save as html". It's rather frightening, actually, to see the actual code.
Office output is fully XML/XSL transform compliant - which is why Opera can handle it perfectly fine.
Also, a lot of the stuff in there is for round-tripping; it doesn't get used by a browser for display - the XSL transform just deletes it to all intents and purposes.
The thing is DOC is a compound file format. Meaning it is made up of various serialized data streams from embedded components. Word itself won't even know what many parts of a DOC file means, it'll just pass it on to Visio, Excel, Photoshop etc to read and understand.
That's actually not necessarily the case; OLE has a mechanism known as "View Caching" which keeps a snapshot of the embedded data in a form which can be displayed or printed in the document without the generating application/control needing to be present on the machine that's viewing the document. You can't edit it, but you can view it or print it - and unless you need to mess with the document (most people just read it), that's enough.
Now i just have one question WHO IN THERE RIGHT MIND WOULD WANT TO SEE BETTER THAN 20/20 I mean think about it. The only reason i would see good reason for this would be for soldiers so they can see farther away without binoculrs Thank you for reading my rant
With good glasses, I can see better than 20/20. For me, it's a matter of whenever I look at anything less than my norm, I get massive headaches because of the eyestrain and brainache involved (my brain actively complains that things are out of focus that should be in sharp focus, and tries its hardest to compensate). Net result: I end up needing a lot more sleep than I should.
It's a nightmare I live with every day. But when it comes down to it; why shouldn't you want to be able to see a road sign half a mile a way - and still be able to read it? Or a car license plate at triple the passing-distance for the driving test? Or even to be able to read really tiny text without invoking manual zoom (bringing it up to your eyeball).
"For years David has been way out in front exploring how we could enhance people's vision beyond what is normally thought of as perfect vision," says Scott MacRae, one of the world's leading cornea specialists and a widely recognized pioneer in refractive surgery.
I'd just settle for an optometrist who didn't insist on overpowering my vision in both eyes so that I can't focus in the GD'd distance. But of course, "your eyesight is supposed to be between here and here, so you need *these* glasses"... which completely disregards the fact that with less-overpowered glasses, I can take the wings off a gnat with a pistol at 500 yards.
Except for the small fact that you don't need to use a modern LCD panel to use this technology. I used to program quite heavily for my old Apple//c, and on the color output (plain old NTSC) this was made use of in several applications. Televisions *do* use 3-color "pixels", and at least DeluxeDraw used this technique to draw "straight" lines on a page. Also, the rendering engine that Sierra came out with (the name escapes me...) would use this technology to draw vector graphics on the screen.
As any television engineer will tell you though, there's no way of addressing the INDIVIDUAL phosphors on the screen; so no, Apple didn't have "subpixel rendering".
What it does have though is the ability to push its monochrome signal (in composite video/NTSC form) at a high enough frequency (ie. high resolution) that it went out of the defined NTSC bandwidth for a luma signal, and poked its way into the chroma. This is why two pixels together ended up as white (or black); because the width of the on/off pulse was wide enough to be encompassed in the luma part of the signal.
When you half that width, you end up with the pixels poking into the chroma part of the signal; depending on the phase (ie if it's the left or right hand part of the pixel pair that's set), you end up with green or magenta.
So it's not quite subpixel resolution. And it's useless for antialiasing (the luminosity distribution between white, black, green and magenta has obviously not been chosen to give antialiasing a helping hand). Well, you can get a half-level, I guess, if you use Magenta. But that's about it.
In conclusion, Apple had a way of forcing color out of a monochrome signal (much like the ZX81, which gave you blue and yellow on a PAL screen if you futzed with the output display), but it wasn't anything to do with splitting pixels, or subpixel rendering, or any kind of attempt to increase the effective resolution of the display. Because believe it or not, if you magnify that television display, more than one phosphor will be lit-up green for the green pixels, and more than one phosphor will be lit-up magenta for the magenta pixels.
Of course, getting Steve Gibson to acknowledge this (especially as he dissed Microsoft as copying Apple, and then implemented his "Free n Clear" with a several-orders-of-magnitude more complicated algorithm to reduce color fringing without batting an eyelid) is a task left to the reader.
Simon
Re:Standard Engineering Practice from the 1980's
on
Cleartype In Depth
·
· Score: 1
When Microsoft mentioned this around two years ago, my advisor posted his application of standard engineering practice (i.e., non-patentable) technique for making use of LCD subpixels. He posted it on the WWW simply to ensure that no company can patent these obvious, but perhaps useful, methods.
The thing is... his method appears to use a simple box-filter; not the complex filter used in ClearType.
The difference may be marginal; ClearType certainly looks better on my HP Jornada than your advisor's solution though. And the difference is what counts; it's the type of filtering algorithm invented that is patentable - and that algorithm is an order of magnitude more complex than the simple one your advisor came up with (similar to Steve Gibson's one).
Not to mention the other gears and cogs involved in getting it up onscreen; they're a siderunner.
The real hidden/obfuscated API use is likely to be in Office and such, not in the devtools. (That would be why a bunch of system DLLs shipped with Office). Since April 1999 is not really all that long (About the time the MS/DOJ thing was getting going, Hmmmmmm....).
The thing is, why not suggest something that Microsoft would have an advantage over everyone else with in doing so?
I can't see anything in Office that with time and developers, anyone else could do just as efficiently or even more efficiently.
Please though - suggest something that Microsoft has an advantage over everyone else with in the Office suite - one that they gain by knowing "hidden" APIs. And I'll gladly try to provide you with my way of doing the same thing going off the documentation available on http://msdn.microsoft.com
One reason why Microsoft may have a perf. advantage over other people on this kind of thing is the fact that they schedule in performance improvements, something that I rarely (if ever) see in most other software companies. Most places, you're code complete and it goes out the door. MS actually spends time optimizing the codebase before doing that. They spent about 4 or 5 months (IIRC) doing this with IE, and about the same with Office.
Question then is, did you use the publicly published Visual Studio, or an internal version? There may be a difference in the tool suite that could make a major difference in the performance of the final product.
The internal one. Except NT, which uses its own compiler that they wrote (kind of like MACOS using their own agressive compiler). Though the NT one is based on the VC one.
The thing is, I was in the devtools department. Until Visual Studio hits beta and starts getting agressively tested, everyone outside of developer tools is using the latest retail version of Visual Studio. Also, MSDN is available internally in two flavors; the online version (at http://msdn.microsoft.com) and one that's shared out from a network drive (it comes with an MSDN subscription, and is obstensibly less up-to-date than the online one). Which, IIRC, were both the latest publically available MSDN libraries.
I'd say that the major differences in the performance of the final products would be due to little things, like not using malloc() or free() - or even the C-runtime libs, and using hand-crafted versions instead. Reading the memory management docs carefully and thoroughly provides bonuses too - for example, you wouldn't want to use malloc() for a webserver. You'd want to use VirtualAlloc() or create a number of separate heaps using GlobalAlloc().
In other words, write to the OS instead of to the C libs. That gains you an impressive across-the-board performance increase generally.
But if you've got any specific performance problems you're talking about, let me know, and I'll see if there's any tricks I know of that I can answer.
Simon ps. Currently, I work for Sierra Home... there's nothing that we can't do that Microsoft can do - short of shipping new system DLLs (a la Office). But since April 1999, that practice has been *stopped* from on high to improve TCO and reduce DLL hell - service packs only is the practice now.
Undocumented calls in MS APIs fall into three categories: The ones that really ARE stable and used by their apps, the ones that can change at any time, and the ones that will be stable until the competition takes advantage of it. MS applications developers (of course) are told which is which. The rest are stuck guessing.
I guess they forgot to tell me all that good stuff while I was there. Because all our team ever used was the source code to our own product, and the documentation available on MSDN.
If you buy a car does Ford tell you you can't modify it! No of course they don't. It doesn't belong to MS. You telling me Compaq has no right to change or modify the software on their machines?
If you buy a car, it's the same as you buying a machine from Compaq - which you can't change or modify without losing the right to tech support.
When Compaq buys Windows from MS, it's the same as a dealership buying a car from Ford. Ford has a certain set of rules which decide what is present in any given car - and which determine what the dealership can or can't do to that car and still keep the warranty (or even sell the car at all).
This is in part to keep their costs down, but also because they advertize their cars as having a certain set of functionality, which they support (with aftermarket parts, maintenance manuals, etc). The dealerships don't get much leeway at all.
Same thing applies to Microsoft - they advertize a certain set of functionality which people expect to be in Windows when they buy a Compaq machine running Windows. So Compaq can always add stuff, but they can't remove anything.
Seems fine to me. But as an addendum; how about I released a Linux distribution where I thought that well, the Linux kernel was a bit crap at something*... so I swap it out with a kernel I wrote myself. Can I still sell that as Linux? Probably not. So why should Microsoft be treated any differently?
Simon *not that I'm saying it is crap at anything; this is hypothetical.
Last time I checked, IE can't do any of the PNG transparency features, whether normal "GIF"-style or PNG's cool multi-level transparency. Therefore, it doesn't really display PNG. (i.e., an ASCII editor can read a.doc file, but not correctly.) Netscape does the same thing.
Unless you've got Quicktime installed (which steals the MIME type and then proceeds to incorrectly display transparent PNGs), IE 5 does indeed display PNGs correctly - with full transparency and gamma correction.
Therefore, IE 5 does really display PNG. IE 4 may be a different matter.
Just think: PNG has been out for 5 years, but is still not widely adopted. Why? Because the programs that most people use to display files, don't display it.
With troff, you can just type "rm troff" and it's gone. You can't remove IE (not easily - you can remove parts of it, including iexplore.exe, but parts of it will always remain on the system). But the main point was that MS wouldn't even let OEM's put Netscape on their computers, they had to use Internet Explorer. This is clearly anticompetitive.
Never the case actually. The issue was that Compaq wanted to remove Internet Explorer and replace it with Netscape. NOT ship them both. This was what Microsoft griped at - they could ship both happily, one icon above the other on the desktop. But they weren't allowed to remove IE from the desktop or from the system.
Which as far as I'm concerned, is perfectly valid. It's their OS after all. And that move can't be seen as anticompetitive can it?
The problem with browsers is that it's easy to do the simple stuff fast, HTML, simple CSS, all that stuff, but then it gets more complicated real quick, JavaScript, complex CSS, Java,... Even Opera still has lots of JavaScript problems (hell, even IE has lots of JavaScript problems, regarding that Netscape designed the language and IE fucked it up).
Netscape doesn't follow the ECMAScript standard (it's not Javascript that you have to be compliant with any more - it's ECMAScript). Netscape also has a buggy DOM model (LAYERs... jesus). IE and OPERA at least support both of those correctly.
Modifications To Monopoly Laws, (Score:5) by JamesSharman (james@exaflop.org) on 11:04 AM June 4th, 2000 EST (#23) (User Info) http://www.exaflop.org
This is a slight side track to the original question but recently I have started to feel strongly that a small alteration to current monopoly law could allow everyone to compete on a level playing field. I have found their to be some misunderstanding as to the purpose of monopoly law, it is not illegal to hold a monopoly but it is illegal to abuse one. I would propose that once a monopoly in an area such as software/operating systems had been established (such as in the current Microsoft case) the company in question should be forced to open it's specifications to file formats, protocols and other proprietary systems that limit interoperability.
If Microsoft were forced to open all it's specifications it be far easier to build an office environment in which other systems played a more crucial role. I personally feel that options currently on the table to deal with Microsoft's abuse of power could adversely affect the software industry in ways that will harm everyone. If instead the kind of forced sharing of information I propose was in place the balance of power would change gradually. Software would appear that could talk to an exchange server alongside server software that outlook is happy communicating with.
They already ARE open. You can download them from various places on the net. There are various Open Source fileconverters based on them. You can get them on the Jan 1999 edition of the MSDN library.
Well, in that case, light has mass, and therefore, *loses his train of thought*... i dunno, a lotta physics assumptions are wrong I'm guessing.. i've never taken physics.
Of course light has mass - E=mc^2 and all that jazz.
However, light has zero rest mass; that is, if you ever had a photon of light that was stationary wrt. your reference frame, it'd have no mass.
Given that light is always travelling at C, regardless of the reference frame, this can't happen though. So yes, photons have mass.:)
(btw: photons still travel at C in non-vacuum media too, but there's a whole load of other effects at work that make the *observed* speed of light lower... it's not always the same photon the whole way through:))
Seems counter-intuitive. If gravity propagates at c, then a black hole would 'capture' it's own gravity inside it's own gravity well. Even taking into consideration that a gravity well may not collapse into a black hole in any finite amount of time, as the well collapses towards the event horizon, the propagation of the gravitational field would slow down as the time frame slows, which would cause an orbiting object to orbit, not where the proto-blackhole was a minute ago, but where it was a century or a millenium ago.
It's the delta-G that travels at C, not the G itself. Think of it as a rubber sheet. Sure, the black-hole stops null-line particles (eg. photons) from getting out, but they're travelling on *top* of space. The gravitational waves *are* the space itself. Gravity is also weird; gravitons would appear to affect other particles, but not each other.
The problem with that though is how fast you can switch the pulse on/off. At some point, you hit problems with the fact that at a certain pulse rate, the pulse itself becomes modulation of a carrier wave, and thus has to obey the other physics (ie. a signal going -_-_-_-_ is physically identical to the same wave with the same length of peaks and troughs as your ones and zeroes).
It's also likely that interference effects would get in the way of it too. At some point, you're no longer dealing with a faster way of sending the information over a given distance, but rather with the signal's bandwidth instead.
[ping! a lightbulb goes on]
In fact, you might well want to look at it that way. The bandwidth of the channel determines how much information can be sent at a given time; once the bandwidth approaches saturation for the speed of light through that medium, it would probably disrupt the effect seen.
The flaw is this: if you have an evanescent wave affecting the outcome of the experiment, you switch the properties of the interface at which the wave is being generated.
A simple way of observing this is to do the following:
Set up a glass prism, with light totally-internally reflecting on the back face of the prism. (the evanescent wave comes out of that face of the prism, but is not yet "realized").
Get another prism, put its back face against the backface of the prism. Provided that the gap between faces is less than the decay-length of the prism (which is why you generally do this experiment with microwaves in a lab), then what happens is that the back face no longer totally-internally reflects, and instead becomes transmissive, because the evanescent wave can now be transmitted before it decays.
The gap size then can be modified to determine how much of the wave is transmitted straight through (based on how much the evanescent wave decays), and how much of the wave is reflected (namely, the amount the wave decays before resuming transmission in an appropriate medium, is the amount that's reflected).
This effect *is* seen all the time in quantum physics; it's the principle behind tunnelling (except of course, with QM, it's an all or nothing affair; either it tunnels or it doesn't, and so you have to start looking at it in terms of probabilities, rather than the amount of wave that's transmitted).
Feynman described *exactly* this effect in his lectures on physics; a particle comes in, hits a barrier, and then crosses the barrier as an *antiparticle* (that is, as a particle going backwards through time; ie. faster than light). Another particle is then generated on the other side of the barrier, where the antiparticle is reflected *back* in time to destroy the original particle.
The problem is, of course, getting the gap big enough and still having the signal not decay too early.
Now personally, I have my eye on another method of faster than light transmission involving particle/antiparticle creation events, but its been too long since my degree, and as such I don't have the grounding or the math to check up on it. Mind you, if I ever win the lottery, I'll fund the guys at CERN to see if I'm correct. The experiment is dead simple, and it'll either work or not.
Just get a lot of sprites with that little 'x' facing in all directions, keep track of the 'rotation': if the X shows, choose the relevant sprite. If the X is facing away- always use a featureless blank ping-pong ball sprite.
Nice idea, but you're talking 256 color sprites, at least 256 different sizes (1x1 -> 256x256), each in different rotations - say 51471 different pixels (centre spot coordinate for the largest of the images). And that's not including all the ones where less than half of the X is visible. Soooo....
Currently I get 3.2Gb needed to store all the different positions. I've not seen the moving demo, so I can't tell you how valid my estimate of the number of different images needed is. However, even for not-so-smooth motion (100 different angles), you'd need 6.4Mb to store all the data. Which is not only causes cache-coherency problems, it's also more than most video cards can handle in terms of textures.
Not to mention that it wouldn't be perspective correct, which those balls appear to be.
OK... I missed that single line. Why it uses Outlook to get a MAPI interface (instead of just invoking one directly), I have no idea... but you're absolutely correct - it does.
Not quite true. Outlook has a nasty tendency to run the script merely by having the e-mail opened (even though the user never opened the attachment). It is the auto-running of certain attachments that makes Outlook particularly vulnerable
Oh really? Then if you'd like to explain why this DIDN'T happen when I opened the ILOVEYOU email in both Outlook 2000 and Outlook Express 5.1, I'd love to hear it.
Please, talk from experience. And if you're talking from experience, tell me which version of Outlook has this alleged problem, so I can independently investigate your claim.
Of course, you're posting anonymously. Which is another reason to assume that you're just a FUD spreader.
The fact that Outlook installs the capability to run executable code WITHOUT a human's capability to stop it, that is the problem, the security hole, the bug. It is a simple thing to add this kind of safety check, and Microsoft wont do it.
So does the command-line... so what?
But the important thing to remember here is: Outlook and Outlook Express do NOT autorun the scripts. They ask you if you want to Save or Run them when you CLICK on the attachment. The default is to Save, and the default button is "Cancel". There's a big fat warning saying "This is an executable file. It could be a virus... are you sure you want to do this?"
If you would like to add several more steps, feel free.
Slashdot Mirror
MS already does this, with HTML^H^H^H^Hrubbish that gets spat out from Word2k, when you do a "save as html". It's rather frightening, actually, to see the actual code.
Office output is fully XML/XSL transform compliant - which is why Opera can handle it perfectly fine.
Also, a lot of the stuff in there is for round-tripping; it doesn't get used by a browser for display - the XSL transform just deletes it to all intents and purposes.
Simon
The thing is DOC is a compound file format. Meaning it is made up of various serialized data streams from embedded components. Word itself won't even know what many parts of a DOC file means, it'll just pass it on to Visio, Excel, Photoshop etc to read and understand.
That's actually not necessarily the case; OLE has a mechanism known as "View Caching" which keeps a snapshot of the embedded data in a form which can be displayed or printed in the document without the generating application/control needing to be present on the machine that's viewing the document. You can't edit it, but you can view it or print it - and unless you need to mess with the document (most people just read it), that's enough.
Simon
Now i just have one question
WHO IN THERE RIGHT MIND WOULD WANT TO SEE BETTER THAN 20/20
I mean think about it. The only reason i would see good reason for this would be for soldiers so they can see farther away without binoculrs Thank you for reading my rant
With good glasses, I can see better than 20/20. For me, it's a matter of whenever I look at anything less than my norm, I get massive headaches because of the eyestrain and brainache involved (my brain actively complains that things are out of focus that should be in sharp focus, and tries its hardest to compensate). Net result: I end up needing a lot more sleep than I should.
It's a nightmare I live with every day. But when it comes down to it; why shouldn't you want to be able to see a road sign half a mile a way - and still be able to read it? Or a car license plate at triple the passing-distance for the driving test? Or even to be able to read really tiny text without invoking manual zoom (bringing it up to your eyeball).
SImon
"For years David has been way out in front exploring how we could enhance people's vision beyond what is normally thought of as perfect vision," says Scott MacRae, one of the world's leading cornea specialists and a widely recognized pioneer in refractive surgery.
I'd just settle for an optometrist who didn't insist on overpowering my vision in both eyes so that I can't focus in the GD'd distance. But of course, "your eyesight is supposed to be between here and here, so you need *these* glasses"... which completely disregards the fact that with less-overpowered glasses, I can take the wings off a gnat with a pistol at 500 yards.
Simon
Except for the small fact that you don't need to use a modern LCD panel to use this technology. I used to program quite heavily for my old Apple //c, and on the color output (plain old NTSC) this was made use of in several applications. Televisions *do* use 3-color "pixels", and at least DeluxeDraw used this technique to draw "straight" lines on a page. Also, the rendering engine that Sierra came out with (the name escapes me...) would use this technology to draw vector graphics on the screen.
As any television engineer will tell you though, there's no way of addressing the INDIVIDUAL phosphors on the screen; so no, Apple didn't have "subpixel rendering".
What it does have though is the ability to push its monochrome signal (in composite video/NTSC form) at a high enough frequency (ie. high resolution) that it went out of the defined NTSC bandwidth for a luma signal, and poked its way into the chroma. This is why two pixels together ended up as white (or black); because the width of the on/off pulse was wide enough to be encompassed in the luma part of the signal.
When you half that width, you end up with the pixels poking into the chroma part of the signal; depending on the phase (ie if it's the left or right hand part of the pixel pair that's set), you end up with green or magenta.
So it's not quite subpixel resolution. And it's useless for antialiasing (the luminosity distribution between white, black, green and magenta has obviously not been chosen to give antialiasing a helping hand). Well, you can get a half-level, I guess, if you use Magenta. But that's about it.
In conclusion, Apple had a way of forcing color out of a monochrome signal (much like the ZX81, which gave you blue and yellow on a PAL screen if you futzed with the output display), but it wasn't anything to do with splitting pixels, or subpixel rendering, or any kind of attempt to increase the effective resolution of the display. Because believe it or not, if you magnify that television display, more than one phosphor will be lit-up green for the green pixels, and more than one phosphor will be lit-up magenta for the magenta pixels.
Of course, getting Steve Gibson to acknowledge this (especially as he dissed Microsoft as copying Apple, and then implemented his "Free n Clear" with a several-orders-of-magnitude more complicated algorithm to reduce color fringing without batting an eyelid) is a task left to the reader.
Simon
When Microsoft mentioned this around two years ago, my advisor posted his application of standard engineering practice (i.e., non-patentable) technique for making use of LCD subpixels. He posted it on the WWW simply to ensure that no company can patent these obvious, but perhaps useful, methods.
The thing is... his method appears to use a simple box-filter; not the complex filter used in ClearType.
The difference may be marginal; ClearType certainly looks better on my HP Jornada than your advisor's solution though. And the difference is what counts; it's the type of filtering algorithm invented that is patentable - and that algorithm is an order of magnitude more complex than the simple one your advisor came up with (similar to Steve Gibson's one).
Not to mention the other gears and cogs involved in getting it up onscreen; they're a siderunner.
Simon
The real hidden/obfuscated API use is likely to be in Office and such, not in the devtools. (That would be why a bunch of system DLLs shipped with Office). Since April 1999 is not really all that long (About the time the MS/DOJ thing was getting going, Hmmmmmm....).
The thing is, why not suggest something that Microsoft would have an advantage over everyone else with in doing so?
I can't see anything in Office that with time and developers, anyone else could do just as efficiently or even more efficiently.
Please though - suggest something that Microsoft has an advantage over everyone else with in the Office suite - one that they gain by knowing "hidden" APIs. And I'll gladly try to provide you with my way of doing the same thing going off the documentation available on http://msdn.microsoft.com
One reason why Microsoft may have a perf. advantage over other people on this kind of thing is the fact that they schedule in performance improvements, something that I rarely (if ever) see in most other software companies. Most places, you're code complete and it goes out the door. MS actually spends time optimizing the codebase before doing that. They spent about 4 or 5 months (IIRC) doing this with IE, and about the same with Office.
Simon
Question then is, did you use the publicly published Visual Studio, or an internal version? There may be a difference in the tool suite that could make a major difference in the performance of the final product.
The internal one. Except NT, which uses its own compiler that they wrote (kind of like MACOS using their own agressive compiler). Though the NT one is based on the VC one.
The thing is, I was in the devtools department. Until Visual Studio hits beta and starts getting agressively tested, everyone outside of developer tools is using the latest retail version of Visual Studio. Also, MSDN is available internally in two flavors; the online version (at http://msdn.microsoft.com) and one that's shared out from a network drive (it comes with an MSDN subscription, and is obstensibly less up-to-date than the online one). Which, IIRC, were both the latest publically available MSDN libraries.
I'd say that the major differences in the performance of the final products would be due to little things, like not using malloc() or free() - or even the C-runtime libs, and using hand-crafted versions instead. Reading the memory management docs carefully and thoroughly provides bonuses too - for example, you wouldn't want to use malloc() for a webserver. You'd want to use VirtualAlloc() or create a number of separate heaps using GlobalAlloc().
In other words, write to the OS instead of to the C libs. That gains you an impressive across-the-board performance increase generally.
But if you've got any specific performance problems you're talking about, let me know, and I'll see if there's any tricks I know of that I can answer.
Simon
ps. Currently, I work for Sierra Home... there's nothing that we can't do that Microsoft can do - short of shipping new system DLLs (a la Office). But since April 1999, that practice has been *stopped* from on high to improve TCO and reduce DLL hell - service packs only is the practice now.
Undocumented calls in MS APIs fall into three categories: The ones that really ARE stable and used by their apps, the ones that can change at any time, and the ones that will be stable until the competition takes advantage of it. MS applications developers (of course) are told which is which. The rest are stuck guessing.
I guess they forgot to tell me all that good stuff while I was there. Because all our team ever used was the source code to our own product, and the documentation available on MSDN.
That's it. Nothing more.
Simon
If you buy a car does Ford tell you you can't modify it! No of course they don't. It doesn't belong to MS. You telling me Compaq has no right to change or modify the software on their machines?
If you buy a car, it's the same as you buying a machine from Compaq - which you can't change or modify without losing the right to tech support.
When Compaq buys Windows from MS, it's the same as a dealership buying a car from Ford. Ford has a certain set of rules which decide what is present in any given car - and which determine what the dealership can or can't do to that car and still keep the warranty (or even sell the car at all).
This is in part to keep their costs down, but also because they advertize their cars as having a certain set of functionality, which they support (with aftermarket parts, maintenance manuals, etc). The dealerships don't get much leeway at all.
Same thing applies to Microsoft - they advertize a certain set of functionality which people expect to be in Windows when they buy a Compaq machine running Windows. So Compaq can always add stuff, but they can't remove anything.
Seems fine to me. But as an addendum; how about I released a Linux distribution where I thought that well, the Linux kernel was a bit crap at something*... so I swap it out with a kernel I wrote myself. Can I still sell that as Linux? Probably not. So why should Microsoft be treated any differently?
Simon
*not that I'm saying it is crap at anything; this is hypothetical.
Last time I checked, IE can't do any of the PNG transparency features, whether normal "GIF"-style or PNG's cool multi-level transparency. Therefore, it doesn't really display PNG. (i.e., an ASCII editor can read a .doc file, but not correctly.) Netscape does the same thing.
Unless you've got Quicktime installed (which steals the MIME type and then proceeds to incorrectly display transparent PNGs), IE 5 does indeed display PNGs correctly - with full transparency and gamma correction.
Therefore, IE 5 does really display PNG. IE 4 may be a different matter.
Simon
Just think: PNG has been out for 5 years, but is still not widely adopted. Why? Because the programs that most people use to display files, don't display it.
IE displays PNG.
Simon
With troff, you can just type "rm troff" and it's gone. You can't remove IE (not easily - you can remove parts of it, including iexplore.exe, but parts of it will always remain on the system). But the main point was that MS wouldn't even let OEM's put Netscape on their computers, they had to use Internet Explorer. This is clearly anticompetitive.
Never the case actually. The issue was that Compaq wanted to remove Internet Explorer and replace it with Netscape. NOT ship them both. This was what Microsoft griped at - they could ship both happily, one icon above the other on the desktop. But they weren't allowed to remove IE from the desktop or from the system.
Which as far as I'm concerned, is perfectly valid. It's their OS after all. And that move can't be seen as anticompetitive can it?
Simon
The problem with browsers is that it's easy to do the simple stuff fast, HTML, simple CSS, all that stuff, but then it gets more complicated real quick, JavaScript, complex CSS, Java, ...
Even Opera still has lots of JavaScript problems (hell, even IE has lots of JavaScript problems, regarding that Netscape designed the language and IE fucked it up).
Netscape doesn't follow the ECMAScript standard (it's not Javascript that you have to be compliant with any more - it's ECMAScript). Netscape also has a buggy DOM model (LAYERs... jesus). IE and OPERA at least support both of those correctly.
Simon
Though the stuff you can get here;
http://www.wotsit.org/search.asp?s=text
Which is distilled (read: copied) from the MS documentation, seems clear enough for a lot of people to get a damn good handle on it.
Modifications To Monopoly Laws, (Score:5)
by JamesSharman (james@exaflop.org) on 11:04 AM June 4th, 2000 EST (#23)
(User Info) http://www.exaflop.org
This is a slight side track to the original question but recently I have started to feel strongly that a small alteration to current monopoly law could allow everyone to compete on a level playing field. I have found their to be some misunderstanding as to the purpose of monopoly law, it is not illegal to hold a monopoly but it is illegal to abuse one. I would propose that once a monopoly in an area such as software/operating systems had been established (such as in the current Microsoft case) the company in question should be forced to open it's specifications to file formats, protocols and other proprietary systems that limit interoperability.
If Microsoft were forced to open all it's specifications it be far easier to build an office environment in which other systems played a more crucial role. I personally feel that options currently on the table to deal with Microsoft's abuse of power could adversely affect the software industry in ways that will harm everyone. If instead the kind of forced sharing of information I propose was in place the balance of power would change gradually. Software would appear that could talk to an exchange server alongside server software that outlook is happy communicating with.
They already ARE open. You can download them from various places on the net. There are various Open Source fileconverters based on them. You can get them on the Jan 1999 edition of the MSDN library.
How much more open do they have to be?
Simon
Well, in that case, light has mass, and therefore, *loses his train of thought* ... i dunno, a lotta physics assumptions are wrong I'm guessing.. i've never taken physics.
:)
:))
Of course light has mass - E=mc^2 and all that jazz.
However, light has zero rest mass; that is, if you ever had a photon of light that was stationary wrt. your reference frame, it'd have no mass.
Given that light is always travelling at C, regardless of the reference frame, this can't happen though. So yes, photons have mass.
(btw: photons still travel at C in non-vacuum media too, but there's a whole load of other effects at work that make the *observed* speed of light lower... it's not always the same photon the whole way through
Si
Seems counter-intuitive. If gravity propagates at c, then a black hole would 'capture' it's own gravity inside it's own gravity well. Even taking into consideration that a gravity well may not collapse into a black hole in any finite amount of time, as the well collapses towards the event horizon, the propagation of the gravitational field would slow down as the time frame slows, which would cause an orbiting object to orbit, not where the proto-blackhole was a minute ago, but where it was a century or a millenium ago.
It's the delta-G that travels at C, not the G itself. Think of it as a rubber sheet. Sure, the black-hole stops null-line particles (eg. photons) from getting out, but they're travelling on *top* of space. The gravitational waves *are* the space itself. Gravity is also weird; gravitons would appear to affect other particles, but not each other.
Simon
The problem with that though is how fast you can switch the pulse on/off. At some point, you hit problems with the fact that at a certain pulse rate, the pulse itself becomes modulation of a carrier wave, and thus has to obey the other physics (ie. a signal going -_-_-_-_ is physically identical to the same wave with the same length of peaks and troughs as your ones and zeroes).
It's also likely that interference effects would get in the way of it too. At some point, you're no longer dealing with a faster way of sending the information over a given distance, but rather with the signal's bandwidth instead.
[ping! a lightbulb goes on]
In fact, you might well want to look at it that way. The bandwidth of the channel determines how much information can be sent at a given time; once the bandwidth approaches saturation for the speed of light through that medium, it would probably disrupt the effect seen.
The flaw is this: if you have an evanescent wave affecting the outcome of the experiment, you switch the properties of the interface at which the wave is being generated.
A simple way of observing this is to do the following:
Set up a glass prism, with light totally-internally reflecting on the back face of the prism. (the evanescent wave comes out of that face of the prism, but is not yet "realized").
Get another prism, put its back face against the backface of the prism. Provided that the gap between faces is less than the decay-length of the prism (which is why you generally do this experiment with microwaves in a lab), then what happens is that the back face no longer totally-internally reflects, and instead becomes transmissive, because the evanescent wave can now be transmitted before it decays.
The gap size then can be modified to determine how much of the wave is transmitted straight through (based on how much the evanescent wave decays), and how much of the wave is reflected (namely, the amount the wave decays before resuming transmission in an appropriate medium, is the amount that's reflected).
This effect *is* seen all the time in quantum physics; it's the principle behind tunnelling (except of course, with QM, it's an all or nothing affair; either it tunnels or it doesn't, and so you have to start looking at it in terms of probabilities, rather than the amount of wave that's transmitted).
Feynman described *exactly* this effect in his lectures on physics; a particle comes in, hits a barrier, and then crosses the barrier as an *antiparticle* (that is, as a particle going backwards through time; ie. faster than light). Another particle is then generated on the other side of the barrier, where the antiparticle is reflected *back* in time to destroy the original particle.
The problem is, of course, getting the gap big enough and still having the signal not decay too early.
Now personally, I have my eye on another method of faster than light transmission involving particle/antiparticle creation events, but its been too long since my degree, and as such I don't have the grounding or the math to check up on it. Mind you, if I ever win the lottery, I'll fund the guys at CERN to see if I'm correct. The experiment is dead simple, and it'll either work or not.
Simon
Just get a lot of sprites with that little 'x' facing in all directions, keep track of the 'rotation': if the X shows, choose the relevant sprite. If the X is facing away- always use a featureless blank ping-pong ball sprite.
Nice idea, but you're talking 256 color sprites, at least 256 different sizes (1x1 -> 256x256), each in different rotations - say 51471 different pixels (centre spot coordinate for the largest of the images). And that's not including all the ones where less than half of the X is visible. Soooo....
Currently I get 3.2Gb needed to store all the different positions. I've not seen the moving demo, so I can't tell you how valid my estimate of the number of different images needed is. However, even for not-so-smooth motion (100 different angles), you'd need 6.4Mb to store all the data. Which is not only causes cache-coherency problems, it's also more than most video cards can handle in terms of textures.
Not to mention that it wouldn't be perspective correct, which those balls appear to be.
Simon
Are you running Outlook?
If so, which version?
Please provide proof. I can tell you that I am 100% certain that Outlook 2000 does NOT have the behavior you're claiming it does.
Simon
OK... I missed that single line. Why it uses Outlook to get a MAPI interface (instead of just invoking one directly), I have no idea... but you're absolutely correct - it does.
Simon
Not quite true. Outlook has a nasty tendency to run the script merely by having the e-mail opened (even though the user never opened the attachment). It is the auto-running of certain attachments that makes Outlook particularly vulnerable
Oh really? Then if you'd like to explain why this DIDN'T happen when I opened the ILOVEYOU email in both Outlook 2000 and Outlook Express 5.1, I'd love to hear it.
Please, talk from experience. And if you're talking from experience, tell me which version of Outlook has this alleged problem, so I can independently investigate your claim.
Of course, you're posting anonymously. Which is another reason to assume that you're just a FUD spreader.
The fact that Outlook installs the capability to run executable code WITHOUT a human's capability to stop it, that is the problem, the security hole, the bug. It is a simple thing to add this kind of safety check, and Microsoft wont do it.
So does the command-line... so what?
But the important thing to remember here is:
Outlook and Outlook Express do NOT autorun the scripts. They ask you if you want to Save or Run them when you CLICK on the attachment. The default is to Save, and the default button is "Cancel". There's a big fat warning saying "This is an executable file. It could be a virus... are you sure you want to do this?"
If you would like to add several more steps, feel free.
Simon