- 博客(0)
- 资源 (23)
- 收藏
- 关注
RSS订阅使用VBS设置Word图片水印（docWatermark.vbs）
使用VBS脚本语言，为WORD添加图片水印。
你也可以参照说明，添加文字水印。
其实，Word的水印，就是设置的页眉。
用法： docWaterMark.vbs "C:\Test.doc" "C:\Water.jpg"
你可在批处理中来调用该脚本，就可以实现批量设置水印了。
编写该脚本的初衷是：为了由程序控制添加Word图片水印的功能。
2016-09-04
StandardC99
1 ISO (the International Organization for Standardization) and IEC (the<br>International Electrotechnical Commission) form the specialized system for<br>worldwide standardization. National bodies that are member of ISO or IEC<br>participate in the development of International Standards through technical<br>committees established by the respective org anization to deal with<br>particular fields of technical activity. ISO and IEC technical committees<br>collaborate in fields of mutual interest. Other international organizations,<br>governmental and non-governmental, in liaison with ISO and IEC, also take<br>part in the work.<br>2 International Standards are drafted in accordance with the rules given in the<br>ISO/IEC Directives, Part 3.<br>3 In the field of information technology, ISO and IEC have established a joint<br>technical committee, ISO/IEC JTC 1. Draft International Standards<br>adopted by the joint technical committee are circulated to national bodies<br>for voting. Publication as an International Standard requires approval by at<br>least 75% of the national bodies casting a vote.<br>4 International Standard ISO/IEC 9899 was prepared by Joint Technical<br>Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 22,<br>Programming languages, their environments and system software<br>interfaces. The Working Group responsible for this standard (WG 14)<br>maintains a site on the World Wide Web at<br>http://www.dkuug.dk/JTC1/SC22/WG14/ containing additional<br>information relevant to this standard such as a Rationale for many of the<br>decisions made during its preparation and a log of Defect Reports and<br>Responses.<br>5 This second edition cancels and replaces the first edition,<br>ISO/IEC 9899:1990, as amended and corrected by<br>ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and<br>ISO/IEC 9899/COR2:1996. Major changes from the previous edition<br>include:<br>— restricted character set support via digraphs and <iso646.h><br>(originally specified in AMD1)<br>— wide character library support in <wchar.h> and <wctype.h><br>(originally specified in AMD1)<br>— more precise aliasing rules via effective type<br>— restricted pointers<br>— variable-length arrays<br>— flexible array members<br>— static and type qualifiers in parameter array declarators<br>— complex (and imaginary) support in <complex.h><br>— type-generic math macros in <tgmath.h><br>— the long long int type and library functions<br>— increased minimum translation limits<br>— additional floating-point characteristics in <float.h><br>— remove implicit int<br>— reliable integer division<br>— universal character names (\u and \U)<br>— extended identifiers<br>— hexadecimal floating-point constants and %a and %A printf/scanf<br>conversion specifiers<br>— compound literals<br>— designated initializers<br>— // comments<br>— extended integer types and library functions in <inttypes.h> and<br><stdint.h><br>— remove implicit function declaration<br>— preprocessor arithmetic done in intmax_t/uintmax_t<br>— mixed declarations and code<br>— new block scopes for selection and iteration statements<br>— integer constant type rules<br>— integer promotion rules<br>— vararg macros<br>— the vscanf family of functions in <stdio.h> and <wchar.h><br>— additional math library functions in <math.h><br>— floating-point environment access in <fenv.h><br>— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support<br>— trailing comma allowed in enum declaration<br>— %lf conversion specifier allowed in printf<br>— inline functions<br>— the snprintf family of functions in <stdio.h><br>— boolean type in <stdbool.h><br>— idempotent type qualifiers<br>— empty macro arguments<br>— new struct type compatibility rules (tag compatibility)<br>— additional predefined macro names<br>— _Pragma preprocessing operator<br>— standard pragmas<br>— _ _func_ _ predefined identifier<br>— VA_COPY macro<br>— additional strftime conversion specifiers<br>— LIA compatibility annex<br>— deprecate ungetc at the beginning of a binary file<br>— remove deprecation of aliased array parameters<br>6 Annexes D and F form a normative part of this standard; annexes A, B, C,<br>E, G, H, I, J, the bibliography, and the index are for information only. In<br>accordance with Part 3 of the ISO/IEC Directives, this foreword, the<br>introduction, notes, footnotes, and examples are for information only.<br>Foreword
2008-03-05
Debugging Application
If this were a normal foreword, I'd begin by relating some alarming stories about bug-filled programs and warning that buggy applications are the root of society's evils. I'd probably then go on to spout statistics from a research report about the average number of bugs per 100 LOC (lines of code). These issues are legitimate, but I figure that if you're reading this book, you know that keeping bugs out of your code is important. As I see it, I have three tasks here:<br><br><br>Explain who the heck John Robbins is<br><br><br>Tell you why you want to read this book<br><br><br>Tell some good stories about John Robbins<br><br>My first encounter with John was on a CompuServe forum. He was working on a homebrew debugger and had posted a question about the Microsoft Win32 Debugging API. In jest, he added that if he finished his debugger, maybe he could get a job at NuMega. I noticed the message and replied to him. I also mentioned that, incidentally, NuMega was looking for people (debugger nerds being hard to come by).<br><br>So began John's roller-coaster ride at NuMega. John showed up for his interview wearing a suit (probably his only one) and carrying a stack of neatly formatted floppies that contained his sample code, which was his completed debugger. During the interview, one of NuMega's owners fell asleep. (Or so John thought. The owner was actually focusing very intently.) John figured his chance at a job was gone right there, but in fact, he impressed everyone. A few months after John had been hired, he noticed that I was using one of his sample code disks as a coffee coaster. The truth was, I knew just from talking to him that John was hardcore about debugging, and I didn't need to check out the code.<br><br>In those days, NuMega was pretty small and was completely focused on getting cutting-edge debugging tools into developers' hands. John paid his dues in this crusade. He was so anxious to start work at NuMega that he moved from Virginia to New Hampshire almost immediately and rented one of the first places he found, a small house behind a fire station. Every time the fire station's doors roared open, John's PC lost power. At work, his first assignment was to write BugBench, a utility that demonstrated every error that BoundsChecker could catch. During that time, we rightfully called John the world's buggiest programmer.<br><br>A few months later, John's PC began freezing for roughly 10 seconds every hour or so. Despite his sharp words with the network administrator, no solution was forthcoming. Finally, John got his hands on a very early version of SoftICE for Windows NT (NuMega's kernel debugger). It didn't take long for John to figure out that another engineer had placed a Windows NT service on John's machine that counted to 175 million at random intervals using a time-critical thread. Try as he might, John was never able to top that prank.<br><br>A big part of NuMega in those days was sending engineers to trade shows. John's outgoing personality made him a natural target for the marketing folks, who were eager to include him in the booth presentations. One of the more, ahem, lame concepts involved a skit that had John starring as "a researcher at the Center for Bug Control in Atlanta." John wanted no part of this escapade, so he and another engineer came up with a completely different concept, an idea that became the genesis of the world-famous "Senior Boy and Junior Boy" skit. John was "Senior Boy," which became one of many nicknames John acquired at NuMega. I'll leave the origination of "Sporkie Boy" to your imagination.<br><br>As a footnote to that trade show, it was also where John learned what's really inside those stress-relieving balloons seemingly filled with sand. In this particular instance, the filling appeared to be tiny fragments of walnut shells. As John held the balloon over his head, he managed to puncture it, covering both of us—nay, the entire hotel room—in walnut shells. The shells even managed to find their way into the blankets and sheets of the beds.<br><br>The first half of John's time at NuMega was spent working on all aspects of BoundsChecker. His duties included developing the debugger loop, writing API validation stubs, fixing symbol table bugs, tweaking with the reference-counting algorithm for COM interfaces, and extending the code for streaming program trace information to disk. All in the same day! Debugging a debugging tool, especially one that takes liberties with the operating system, provides plenty of opportunity to hone your debugging skills.<br><br>Often John and I weren't able to use a debugger on the tough problems. One problem in particular I remember was when I ran BoundsChecker on Microsoft's Visual SourceSafe the night before an important beta. It seemed to run fine, but a few minutes later, another engineer noticed that the file dates in Visual SourceSafe were something like "@@1?70." Regular backups weren't yet a part of our engineering process, so I ended up nearly completely destroying the version control database that held the only copy of the source code. Needless to say, the entire company was out for my hide, but John and I knuckled down and discovered that Visual SourceSafe was using some legacy MS-DOS code that trashed our file handles.<br><br>You might be wondering, "Why all these stories?" My point is that John is no academic or abstract theorist. John has walked the walk (and definitely likes to talk the talk). John and I frequently lament the fact that so many programming books are written by people who have little or no commercial development experience and who don't write programs that exceed 100 lines. John was a lead developer on several award-winning products. When he writes, he's conveying information learned from his hard-won experiences.<br><br>When John decides to do something, he does it whole hog. He will wrestle with a subject until he has it completely pinned. "I couldn't figure it out" isn't in John's vocabulary. Before John began his writing career, he offered to help me out with a few functions for a Microsoft Systems Journal (MSJ) column I was working on. I think he spent more time on the code than I did. Because we both now write columns for MSJ, we regularly swap stories on the horrors we encounter while writing the code that accompanies our columns. On many occasions, his descriptions of how far he went to chase down a problem have left me slack-jawed.<br><br>Writing a book requires more than just knowledge of the subject matter. It also requires a desire to communicate this knowledge effectively to the reader. I noticed John's easy way with words in his very first article. I still consider it a treat to read anything by John Robbins. It's a pleasure to read something when I know the author truly understands the subject matter, has a passion for communicating it, and doesn't make it sound more complicated than it needs to.<br><br>John's enthusiasm for writing extends beyond just his articles, his columns, and this book. John leaves his stamp in just about any code he writes, as this excerpt from a classic e-mail I received at work shows:<br><br><br>What is with all this "DISCUSSION" crap John litters the core with? Every damn function header is prefaced with a complete chapter on the sociological implications of using the routine and how planets may misalign if you use them improperly - last month's MSJ was nearly a friggin book, most of it filled with all of this "DISCUSSION" crap - he wrote almost a book in and of itself for his "Form Load" handler. Is the man an author or an engineer? Jeez…<br><br>As you'll see in this book, the answer is both!<br><br>Debugging is a subject that's shrouded in mystery, and in many ways it's an oral tradition. Good texts are sorely needed. The few books available focus mostly on sanitized situations and don't get into the swampy details that effective Windows debugging often entails. From time to time, publishers have approached me about writing a book on debugging, and I've always declined. It's not that I don't know enough about debugging. Rather, I find it difficult to quantify my gut-level debugging knowledge into something that can be put on paper. John doesn't have this problem.<br><br>From my perspective, effective debugging is pretty simple at a high level. I always come back to two tenets:<br><br><br>Know what's supposed to be happening<br><br><br>Know how to use your tools to see what's really happening<br><br>If you have these two things nailed, debugging is usually straightforward. The problem is, both of the above items aren't so easy to pull off. When I say "Know what's supposed to be happening," I don't expect your knowledge to stop at your source code. You have to be able to see both the big picture and the microscopic details. What did the compiler mutate your code into? What happens inside that API call? If you can't answer these questions, you're flying blind.<br><br>I'm not saying that to debug you need to trace through every instruction. Rather, when the need arises, you should be able to keep breaking the problem into smaller and smaller pieces—something John recommends in Chapter 1 of this book. You might also have to dig into components that you don't control to find the cause of a crash. Eventually, you'll find the answer if you go deep enough into the bits. A lot of tracking down bugs requires you to know the intricacies of your language, operating system, and CPU—another topic John covers in Chapter 1. The chapter on the minimum amount of x86 assembly language you should know (Chapter 6) will be an invaluable resource for you.<br><br>Likewise, knowing how to use your tools effectively is critical. Debugging tools have become fairly sophisticated, and many developers never get (or don't take) the opportunity to become familiar with the full range of their tools' capabilities. I'm reminded of a friend who had a brilliant young graphics programmer working for him. When the prodigy's code crashed one day, he had no idea that his debugger could show him a call stack.<br><br>Too many developers learn just enough debugging skills to get them out of their current jam. Often, users overlook great features of debugging tools because the situation in which to use them isn't put into the proper context. Reading through documentation, feature by feature, gets boring, and you learn only the most basic information. John's chapters on power debugging in the Microsoft Visual C++ and Microsoft Visual Basic debuggers (chapters 5 through 7) take you far past the tedium of "step, step, step. Inspect. Step, step, step…"<br><br>When I say debugging is an oral tradition, I mean that most people learn a new debugging skill or technique only when they hear about someone else using it to solve a problem. When you watch a master at work with good debugging tools, you can learn 10 times as much in 30 minutes as you would in a day of reading the documentation by yourself. John is just such a master of debugging. He knows the strengths and weaknesses of all the tools he uses. He also invests his time up front to write great diagnostic code that more than pays for itself later. You can do the same for yourself by making debugging a skill that you continually enhance rather than a chore. This book is chock full of nuggets of John's debugging gold to help speed you on your way.<br><br>Matt Pietrek<br>Hollis, New Hampshire<br>December 1999<br>
2008-03-05
编程高手箴言
国人的骄傲<br><br>本书是作者十余年编程生涯中的技术和经验的总结。内容涵盖了从认识CPU、Windows运行机理、编程语言的运行机理，到代码的规范和风格、分析方法、调试方法和内核优化，内有作者对许多问题的认知过程和透彻的分析，以及优秀和精彩的编程经验。
2008-03-05
UnitConverter
为软件编写人员写的一个小程序，进行二进制、十进制、十六进制；BYTE、KByte、MByte之间的自动转换。并且可以进行简单的数据记录功能，方便对比数据。
2007-11-13
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人