Microsoft admit to quick hacks
-
Makes an honest change. Usually it's dwReserved. Michael :-) Programming is great. First they pay you to introduce bugs into software. Then they pay you to remove them again.
Michael P Butler wrote: Makes an honest change. Usually it's dwReserved. LOL So the millions spent on trial were not lost :) Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
-
LOL what i dont get is, why is it there, it says thaty it is never used, so why put it there :confused:
:suss: Email: theeclypse@hotmail.com URL: http://www.onyeyiri.co.uk
:suss:"All programmers are playwrights and all computers are lousy actors."I'd guess you'll find it works like this: Function doesn't work. Insert new argument for testing purposes. Adjust all testing programs to pass new argument. Fix bug in function. If it ain't broke, don't fix it any more. Rename argument to dwReserved in case you might want to use it in a later version. This has been going on for years, but this time the name gives you a clue as to why :laugh:
-
LOL what i dont get is, why is it there, it says thaty it is never used, so why put it there :confused:
:suss: Email: theeclypse@hotmail.com URL: http://www.onyeyiri.co.uk
:suss:"All programmers are playwrights and all computers are lousy actors."Nnamdi Onyeyiri wrote: it says thaty it is never used, so why put it there I'd say it's good engineering. At the beginning of a design you often don't know exactly what you need, so you design in a little extra. In electronics design, for instance, you build cables with more wires in them than needed, because a future mod may require another couple of signals. In a circuit, you leave a few unused gates in the design, just in case you need to expand it some. In software, you might not, at the beginning of a project, know exactly which parameters you may need to pass down the road. So your data structures might include a parameter or two that don't initially have a defined use. If in the course of development you discover a need for something unexpected, there's already a place to put it without extensive redesign of the whole body of code. I don't know if it's still a significant problem, but memory alignment used to be a hassle in earlier Intel architectures, and padding was used to ensure proper alignment on a word boundary. This Signature is Temporarily Out of Order
-
Nnamdi Onyeyiri wrote: it says thaty it is never used, so why put it there I'd say it's good engineering. At the beginning of a design you often don't know exactly what you need, so you design in a little extra. In electronics design, for instance, you build cables with more wires in them than needed, because a future mod may require another couple of signals. In a circuit, you leave a few unused gates in the design, just in case you need to expand it some. In software, you might not, at the beginning of a project, know exactly which parameters you may need to pass down the road. So your data structures might include a parameter or two that don't initially have a defined use. If in the course of development you discover a need for something unexpected, there's already a place to put it without extensive redesign of the whole body of code. I don't know if it's still a significant problem, but memory alignment used to be a hassle in earlier Intel architectures, and padding was used to ensure proper alignment on a word boundary. This Signature is Temporarily Out of Order
Roger Wright wrote: I'd say it's good engineering. At the beginning of a design you often don't know exactly what you need, so you design in a little extra. In electronics design, for instance, you build cables with more wires in them than needed, because a future mod may require another couple of signals. In a circuit, you leave a few unused gates in the design, just in case you need to expand it some. In software, you might not, at the beginning of a project, know exactly which parameters you may need to pass down the road. So your data structures might include a parameter or two that don't initially have a defined use. If in the course of development you discover a need for something unexpected, there's already a place to put it without extensive redesign of the whole body of code. I don't know if it's still a significant problem, but memory alignment used to be a hassle in earlier Intel architectures, and padding was used to ensure proper alignment on a word boundary. So, explain me CoInitialize(NULL) and CoInitializeEx(NULL, APT_MODEL); Why do the hell they didn't use the dwReserved in CoInitialize to set the apt. model ? Why creating a Ex function that has the same dwReserved, plus the apt. model choice ? Concussus surgo. When struck I rise.
-
Roger Wright wrote: I'd say it's good engineering. At the beginning of a design you often don't know exactly what you need, so you design in a little extra. In electronics design, for instance, you build cables with more wires in them than needed, because a future mod may require another couple of signals. In a circuit, you leave a few unused gates in the design, just in case you need to expand it some. In software, you might not, at the beginning of a project, know exactly which parameters you may need to pass down the road. So your data structures might include a parameter or two that don't initially have a defined use. If in the course of development you discover a need for something unexpected, there's already a place to put it without extensive redesign of the whole body of code. I don't know if it's still a significant problem, but memory alignment used to be a hassle in earlier Intel architectures, and padding was used to ensure proper alignment on a word boundary. So, explain me CoInitialize(NULL) and CoInitializeEx(NULL, APT_MODEL); Why do the hell they didn't use the dwReserved in CoInitialize to set the apt. model ? Why creating a Ex function that has the same dwReserved, plus the apt. model choice ? Concussus surgo. When struck I rise.
Daniel Turini wrote: So, explain me CoInitialize(NULL) and CoInitializeEx(NULL, APT_MODEL); Windows system DLL which passes -1 instead of NULL to achieve something special? ;) Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
-
Roger Wright wrote: I'd say it's good engineering. At the beginning of a design you often don't know exactly what you need, so you design in a little extra. In electronics design, for instance, you build cables with more wires in them than needed, because a future mod may require another couple of signals. In a circuit, you leave a few unused gates in the design, just in case you need to expand it some. In software, you might not, at the beginning of a project, know exactly which parameters you may need to pass down the road. So your data structures might include a parameter or two that don't initially have a defined use. If in the course of development you discover a need for something unexpected, there's already a place to put it without extensive redesign of the whole body of code. I don't know if it's still a significant problem, but memory alignment used to be a hassle in earlier Intel architectures, and padding was used to ensure proper alignment on a word boundary. So, explain me CoInitialize(NULL) and CoInitializeEx(NULL, APT_MODEL); Why do the hell they didn't use the dwReserved in CoInitialize to set the apt. model ? Why creating a Ex function that has the same dwReserved, plus the apt. model choice ? Concussus surgo. When struck I rise.
Daniel Turini wrote: So, explain me CoInitialize(NULL) and CoInitializeEx(NULL, APT_MODEL); Why do the hell they didn't use the dwReserved in CoInitialize to set the apt. model ? Why creating a Ex function that has the same dwReserved, plus the apt. model choice ? To be consistent with their inconsistency. "640K ought to be enough for anybody." Bill Gates
-
Roger Wright wrote: I'd say it's good engineering. At the beginning of a design you often don't know exactly what you need, so you design in a little extra. In electronics design, for instance, you build cables with more wires in them than needed, because a future mod may require another couple of signals. In a circuit, you leave a few unused gates in the design, just in case you need to expand it some. In software, you might not, at the beginning of a project, know exactly which parameters you may need to pass down the road. So your data structures might include a parameter or two that don't initially have a defined use. If in the course of development you discover a need for something unexpected, there's already a place to put it without extensive redesign of the whole body of code. I don't know if it's still a significant problem, but memory alignment used to be a hassle in earlier Intel architectures, and padding was used to ensure proper alignment on a word boundary. So, explain me CoInitialize(NULL) and CoInitializeEx(NULL, APT_MODEL); Why do the hell they didn't use the dwReserved in CoInitialize to set the apt. model ? Why creating a Ex function that has the same dwReserved, plus the apt. model choice ? Concussus surgo. When struck I rise.
Habit, maybe? I don't pretend to read minds. But I do always like to leave myself some wiggle room in a design, hardware or software, and if there's no pressing need to use up my spares during a mod, I'll keep them for later. This Signature is Temporarily Out of Order
-
Daniel Turini wrote: So, explain me CoInitialize(NULL) and CoInitializeEx(NULL, APT_MODEL); Windows system DLL which passes -1 instead of NULL to achieve something special? ;) Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
Tomasz Sowinski wrote: Windows system DLL which passes -1 instead of NULL to achieve something special? I vote this for the most plausible explanation :) Or, for saving some typing: if you have a parameter, you don't need a local variable ;P Maybe I should start calling CoInitialize(rand()) Someday I may discover a totally new apartment model :) Concussus surgo. When struck I rise.
-
Tomasz Sowinski wrote: Windows system DLL which passes -1 instead of NULL to achieve something special? I vote this for the most plausible explanation :) Or, for saving some typing: if you have a parameter, you don't need a local variable ;P Maybe I should start calling CoInitialize(rand()) Someday I may discover a totally new apartment model :) Concussus surgo. When struck I rise.
Daniel Turini wrote: Someday I may discover a totally new apartment model
COINIT_EFFICIENCYMultiple objects can exist within the same apartment and easily share resources, but they steal each other's food and tie up bathrooms for too long in the morning...Shog9
Let me hear you / Make decisions / Without your television
-
Daniel Turini wrote: Someday I may discover a totally new apartment model
COINIT_EFFICIENCYMultiple objects can exist within the same apartment and easily share resources, but they steal each other's food and tie up bathrooms for too long in the morning...Shog9
Let me hear you / Make decisions / Without your television
Shog9 wrote: and tie up bathrooms for too long in the morning... This is what I call a CRITICAL_SECTION ! Concussus surgo. When struck I rise.