TextOut() to a DialogBox ???
in [MFC]
|
From: Peter Olcott on 24 Mar 2010 23:24 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:tnjlq55gn872v0p54bmd89p35hvjct0i18(a)4ax.com... > See below... > > On Wed, 24 Mar 2010 20:07:32 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>message >>news:uIE36l6yKHA.5288(a)TK2MSFTNGP05.phx.gbl... >>> Peter Olcott wrote: >>> >>> >>>> I learned this from an email from Ward Cunningham the >>>> inventor of CRC cards. I asked him if he could only >>>> choose a single criterion measure of code quality what >>>> would it be. He said code size, eliminate redundant >>>> code. >>> >>> He probably meant about reusability Peter. >> >>Yes and code size (lines-of-code) quantified the degree of >>re-use. > **** > Back when I was at the SEI we studied metrics used to > measure reuse, and lines of code was > the least useful and poorest predictor. I spent a couple > years looking at this problem, He actually said code size meaning source code size, and I am sure that he did not mean to make all variable names very short, because this would make the program more complex and not be a measure of the degree of re-use. > talking to some of the key designers and managers in the > field, and generally they would > say "we use lines of code, but nobody trusts it" and give > several cogent reasons it was > meaningless as a metric of reuse, productivity, or > anything else. It is a meaningless measure of programmer productivity, when it is taken to be that more is better. It is not as meaningless as a measure of re-use when it is taken that less is better. What other quantifiable object measure of the specific degree of re-use would you propose? > **** >> >>> >>> In programming, you can code for size or speed. >>> redundant >>> code is faster because you reduce stack overhead. When >>> you code for size, you are reusing code which has stack >>> overhead. >> >>No that is not quite it. Fewer lines-of-code are fewer >>lines-of-code that you ever have to deal with. By >>maximizing >>re-use changes get propagated with fewer changes. > **** > The old "top-down" programming argument. It doesn't > actually work, but Dijkstra made it > sound cool. It looks good until you try to use it in > practice, then it crumbles to dust. > The reason is that decisions get bound top to bottom, and > changing a top-level decision > ripples the whole way down the design tree; and if, at the > lower level, you need to make a > change, it ripples upward. Actually "rips" more correctly > describes the effect. > > Parnas got it right with the notion of module interfaces, > screw the lines of code. A > friend of mine got an award for software accomplishment > when he changed the code review > process to review ONLY the "interface" files (in the true > sense of INTERFACE, that is, no > private methods, no variables, period; only public methods > are in an interface). He said > that it was every bit as productive, and the code reviews > went faster. IBM though so to, > and gave him a corporate recognition award for > contributing to software productivity. > > Lines of code don't matter. Interfaces are all that > matter. Parnas said this in the late > 1960s and early 1970s, and essentially forty years of > history have proven him right. Minimizing the public interface? Yes that does sound like a better measure. Ward's reply was off-the-cuff and informal. > > Part of the role of a good compiler is to peek across > interfaces and produce good code in > spite of the abstractions. The MS C++ compiler is perhaps > the best optimizing compiler I > have ever seen, and I've seen a lot. I've heard the Intel > compiler is pretty good, too, > but I can't afford it. > > [disclosure: Dave Parnas was one of my professors at CMU, > taught one of the toughest > courses I ever took, which was operating systems, and > lectured in the hardware course. I > have a deep respect for him. He is one of the founders of > the field of Software Safety, > and works at a completely different level of specification > than mere mortals] > joe > **** The hardest one for me was compiler construction, it was also my favorite. >> >>> >>> But in the today's world of super fast machines and >>> bloated windows, higher dependency on dlls, proxies and >>> p-code RTL, and high code generated sizes, the code vs >>> speed ideas is, IMO, a thing of the past. >>> >>> Cases in point: >>> >>> 1) .NET, reusability, higher stack overhead, but faster >>> machines makes it all feasible. >>> >>> 2) The evolution of templates. Once a code for speed >>> with >>> the expense of redundant code and bigger size, today, it >>> is doesn't really matter and is more virtualize with >>> functional coding and interfacing. >>> >>> You do want speed, don't get me wrong, but you are not >>> going to waste type not creating reusable code. One >>> thing you can do quickly with functions is to use the >>> inline statement. This is good for low overhead black >>> box >>> functions: >>> >>> inline >>> const DWORD &GetRandom(const DWORD &size) >>> { >>> return (rand()*rand())%size; >>> } >>> >>> This gives the smaller functional programming sizing,yet >>> some speed considerations with reduce stack overhead. >>> >>> >>> -- >>> HLS >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 24 Mar 2010 23:27 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:rgklq5569ggovfognpvlpm03kjtb7vetu3(a)4ax.com... > See below... > On Wed, 24 Mar 2010 15:39:26 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>message >>news:ufF$nt3yKHA.928(a)TK2MSFTNGP05.phx.gbl... >>> Peter Olcott wrote: >>> >>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>> message >>>> news:ndgkq5lbilsibpqql11bi0d0tp6b6psl6q(a)4ax.com... >>> >>> >>>>> If you want text on a dialog box, place a static >>>>> control >>>>> there and use SetWindowText to >>>>> tell it what to display. >>>> >>>> I don't think that will work because I need to specify >>>> every detail of the text, its font, foreground color, >>>> et >>>> cetera. In any case this is all moot now anyway. I am >>>> simply bitblt-ing my memory bitmap to the window. >>>> >>>>> Developing the style of writing directly to a dialog >>>>> box >>>>> surface will eventually uncover a >>>>> large set of problems, none of which you want to deal >>>>> with. >>>>> joe >>>> >>>> This is only for internal testing purposes. >>> >>> Then even more the reason to just use the IDE and >>> controls >>> as to not waste time learning something you will never >>> use >>> anyway - like Intel Chip Caches. :) >>> >>> -- >>> HLS >> >>Here is an interesting note that I don't understand. A >>slight revision (to make it a little less CPU intensive, >>thus more memory intensive) only actually achieves 21 MB >>per >>second of the 12 GB / second maximum RAM speed. (RAM >>speed >>reported by MemTest86). Why is the RAM performance so much less than its capability when the loop below was intentionally made to stress test RAM performance? I read the rest and its already been addressed. >> >>const uint32 size = 100000000; >>std::vector<uint32> Data; >>uint32 Max = 0x3fffffff; >> >> >>void Process() { >> clock_t finish; >> clock_t start = clock(); >> double duration; >> uint32 num; >> for (uint32 N = 0; N < Max; N++) >> num = Data[num]; >> finish = clock(); >> duration = (double)(finish - start) / CLOCKS_PER_SEC; >> printf("%4.2f Seconds\n", duration); >> } >> >>Another thing that I don't understand is that it crashes >>when >> num = Data[num]; >>is replaced by >> num = Data[N]; >> > **** > Another meaningless use of the word "crash". I have no > idea what it does. Does it > generate an access fault? Or a bounds check? Duh. This > is another "gee, my program > doesn't work, what did I do wrong?" question. Of course, > a reasonable bug report would > say "I got an access fault in the above code when the > value N is <value told here>" and > you would also have said how big Data is (how many > elements in it?).. Otherwise, the bug > report is flummery, and cannot be diagnosed. Unless I run > it and obtain the information > that should have been in the bug report. Only amateurs > fail to give relevant information > when an error occurs. > > I note that the std::Vector Data is not actually set to > any value. There is no setsize() > call done to create any objects in the vector, nor any > push_back calls. So it is empty. > Furthermore, the integer num is not initialized, so has an > undefined value (most likely > 0xcccccccc if you are running in debug mode). As > written, the code should not work at > all > > I am curious why QueryProformanceCounter was not used, but > the low-resolution and largely > unreliable clock() function (resolution: 15ms) is used. > joe > **** > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 24 Mar 2010 23:38 See below... On Wed, 24 Mar 2010 20:32:06 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: > >Geoff wrote: > >> I am not sure what you mean by "load low". > > >Its the old mainframe term for "zero fill" > >> In debug mode in my debugger uint32 num is 0xCCCCCCCC so using it as >> an index into a un-sized vector<uint32> yields a GPF. > > >right. > >> In release mode num is initialized from within the stack space >> allocated at link time which would be zeroed in the binary image or >> zeroed, presumably by Windows, before the binary was placed into >> memory. > > >Ahhhhhhh, the stack ok, I think I did hear MS say there would doing >something along these lines to resolve the #1 SECURITY problem: > > stack based buffer overruns > >The #1 exploit hackers look for when overloading an input source >looking for the right size that would trigger maybe a: > > EXCEPTION_CONTINUE_EXECUTION **** This is a value which tells the stack unwinder what to do, it is itself, not an exception. Read about __try/__except to understand what this symbol means. **** > >at the precise point where the virus is piggy backing on the >overflowing buffer. > > xxxxxxxxxx|zzzzzzzzzz|virus > acceptable| overflow |continue address > >So what we are talking about it, I'm sure, its Microsoft new Stack >protection technology now implemented in newer Windows but it long >promised since 2000 since the first CodeRed incident that provided the >proof of concept for all the other CodeRed-like viruses to follow. **** the buffer-overrun detection has been around for a while, it is a C compiler/C-runtime set of checks, but it wouldn't come into play here because there is no stack overrun. Note that the actual data for a std::vector is not allocated on the stack, but on the heap. **** > >I have personal experience with this as we were one of the first >corporate CodeRed victims back in 2001 along with other big corporate >sites. This was the first FBI Computer Crimes case for then new South >East Florida FBI Computer Crime Division just open and I immediately >got them involved. Microsoft was calling us practically every day >about the situation once we got the FBI involved (I should of SUED, >but I was nice. <g>) We were both laying unethical blame for E-Eye >Security people getting a name for themselves by threathening MS to >get a fix in X time, but stupidly released the exploit code and within >hours/days a Russian hacker got into our then IIS 4.0 server installed >a back door getting access to entire network. **** Code Red was a nasty stack overrun virus, and the question is, who should you sue? Intel, for failing to provide no-execute stack segments? Microsoft for exercising Best Practice of the era (which we know to be Bad Practice today, because of buffer overrun viruses). I once spent an intense several hours showing on of my securitly clients how to reverse-engineer Code Red using a kernel debugger, it is a nasty piece of work. The only real defeat is no-execute stack segments, which Intel did not support at the time. And Microsoft only barely supports now (only on the high end servers, not on end-user machines, and why doesn't Intel make this feature available on ALL chips?) **** > >Trust me, it was one of the worst nightmares me and my network guy >ever went thru, staying up for three full days not knowing how far, >how deep they got in, how much our million dollars investment in >software was stolen or not. All we knew as a result was that the >Russion "FBI" Division was involved and it was reported they arrested >the hacker. Anyway, I recall my conversations with the MS Security >Manager and FBI liaison telling me how MS was going to address the >stack buffer overflow problem at the OS - that was 2001 when Windows >2000 was the current OS. ***** It took me out for a week. It took me a couple months to recover and get all my machines back into secured mode. > >> I assumed this was for security and IIRC, was one of the >> reasons Steve Maguire gave for the subtle bugs that appear when going >> from debug build to release build and finding out your application >> GPFs because you forgot to initialize a pointer. > > **** That is why Debug mode initializes every stack variable to 0xCCCCCCCCC (it is an illegal address and will kill you instantly) and every heap element (including uninitialized pointers in newly-allocated code to something like 0xDFDFDFDFDF and ovewrites them on freeing to 0xCDCDCDCD or, in more modern C runtimes, 0xFEEEFEEE. This is all part of the C runtime, not the kernel or anything else. It is also why starting with VS2005, every local variable is "shadowed" by an anonymous BOOL variable. So if you write int n; you get int n = 0xCCCCCCCC; BOOL n_IS_INITIALIZED = FALSE; and all code of the form n = expression; really generates code of the form n = expression n_IS_INITIALIZED = TRUE; and every use of n of the form ..... = .... n .... generates RUNTIME_CHECK_ASSERT(n_IS_INITIALIZED); ... = ....n ... (It is more complex than this, but you get the idea). So these uninitialized values are caught at debug time. Only a real amateur builds release code without checking it out in debug mode first. Or we get those silly people who say "There's something wrong with MFC. In Debug mode I get all these obnoxious ASSERT MessageBoxes but in Release mode I don't get any, so I stopped using Debug mode" to which the only reply is "You are stupid. Those ASSERT failures mean your code is full of bugs. Fix the bugs before building a Release mode version". It is truly hard to believe that someone could be so mind-bogglingly stupid. Of course, it also makes no sense to build a release version without testing a debug version of the same code. joe **** **** >Yes, I am sure it is part of MS stack protection. I knew the compiler >has these switches: > > /Ge force stack checking for all funcs > /Gs[num] control stack checking calls > >But I had the idea that MS did more with Windows Longhorn >(2008/VISTA/7) at the OS level. **** Mostly it is supporting the new no-execute feature on the stack pages. Which Intel does not support in every chip (which should form the basis of a Really Good Class Action Suit) joe > >> I'm one of those who niggles at those little details that otherwise >> escape the "big picture" boys who don't like to debug their code. :) > > >Me too, but I always initialize my code by nature now, even if it a >object. :) Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Goran on 25 Mar 2010 07:35 On Mar 24, 11:45 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: > Peter Olcott wrote: > > void Process() { > > clock_t finish; > > clock_t start = clock(); > > double duration; > > uint32 num; > > for (uint32 N = 0; N < Max; N++) > > num = Data[num]; > > finish = clock(); > > duration = (double)(finish - start) / CLOCKS_PER_SEC; > > printf("%4.2f Seconds\n", duration); > > } > > All I can see is that you have an uninitialized num variable. When > not initialized it can be an random number including one that exceeds Max.. > > So initialize it: > > uint32 num = 0; > for (uint32 N = 0; N < Max; N++) > num = Data[num]; > > and see if that solved it for you. I honestly think that everyone should just ignore this Olcott guy. The amount of incompetence he is showing is staggering (as shown by you up here - AGAIN), and yet, he acts like he knows something all the time. The guy is amazing! (Or, as someone said before "everything is limited, except ignorance" - or something like that). Goran.
From: Hector Santos on 25 Mar 2010 07:53
Goran wrote: > On Mar 24, 11:45 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: >> Peter Olcott wrote: >>> void Process() { >>> clock_t finish; >>> clock_t start = clock(); >>> double duration; >>> uint32 num; >>> for (uint32 N = 0; N < Max; N++) >>> num = Data[num]; >>> finish = clock(); >>> duration = (double)(finish - start) / CLOCKS_PER_SEC; >>> printf("%4.2f Seconds\n", duration); >>> } >> All I can see is that you have an uninitialized num variable. When >> not initialized it can be an random number including one that exceeds Max. >> >> So initialize it: >> >> uint32 num = 0; >> for (uint32 N = 0; N < Max; N++) >> num = Data[num]; >> >> and see if that solved it for you. > > I honestly think that everyone should just ignore this Olcott guy. The > amount of incompetence he is showing is staggering (as shown by you up > here - AGAIN), and yet, he acts like he knows something all the time. > > The guy is amazing! (Or, as someone said before "everything is > limited, except ignorance" - or something like that). You're right Goran, its chewing up valuable time at this point and was kind of wishing for someone to jump into to put a stop this this mad thread by slapping us across the head. But you, we, kinda wish you can turn this guy around. He just refuses to listen. Maybe my last post will show he has no choice but to use multi-threads and get away from this 1 EXE per core nutty idea. Its restricted by port 80 as only one server can bind to port 80. -- HLS |