Writing kernel mode
Microsoft has also taken another measures to enhance the reliability of the platform: Any program running in the kernel mode will actually have a write protected area in memory. If you have used some code segments or string paragraphs in your device driver, you will write some temporary content (such as annotations, etc.) where you are listed as read-only areas, which will be in Windows 2000. Not pass. We do not allow any content in kernel mode to hinder the protection functionality should have, as this will cause the system to crash.
We have found that many device drivers do not follow this rule of Windows 2000. By checking the device driver, the system will determine if the design objective of the device driver is used for Windows NT 4.0 instead of Windows 2000, this rule is not enforced. If so, it will lead to too many device drivers to work properly. For the device drivers written for Windows 2000 or have been upgraded so that the system will force the rule to be enforced on the Directs that work properly on Windows 2000.
Stack consumption increase
In order to illustrate several substantive problems in compatibility, we must understand that the stack space used by Windows 2000 is much larger than Windows NT 4.0. Since we use a unified executable program, the space occupied by Unicode is much more than ever, and we still have more strings or therefore cause the system to be more Multi-stack. We have found that some applications enhance performance by minimizing stack space. If you want to increase the running speed, this is undoubtedly a good idea: it is obvious that the less memory, the faster the speed is running. But unfortunately, they are now too small. As the system and the application are quickly used in stack space, the result is that the application crashes.
To confirm that there is the above problem in your application, you need to check the following settings: If you use the / stack-linker option in the link line, check this option; check in the compiler in the use of StackSize parameters or / f option Stacksize-.def file. You need to retrieve all of these contents to see if they are running on Windows 2000 and confirm that the stack space is not too small.
Win32 API changes
In Windows 2000, the Microsoft Win32 (R) API has many changes; we check several of them, found that there are some compatibility disorders caused in unintentional. The following is some changes that I often encountered during the Windows 2000 test.
We have to support a new input method in Windows 2000. To achieve this, some of the information in WPARAM is required, which is obtained through WM_KEYUP and WM_KEYDOWN messages. We ask you to pass WPARAM to transfer to TranslateMessage. If you don't do this, we will not be able to fully implement the function of this new input method.
Another problem is on DS_SHELLFONT within the dialog structure. If you specify DS_SHELLFONT, you cannot change the font. We use Microsoft Shell DLG 2 as a font; you can change the size, but you can't change the shape.
In the OpenFileName Structure of the Open File dialog, the behavior of the initial directory has a small difference. If OpenFile does not find any file you want to find type, it will directly point to the "My Documents" folder by default.
GetWindowsDirectory returns the system directory for each user. If you are on the Terminal Server, you may find that you cannot get a real system directory, which will be a system directory that is set for specific users. There is a new GetWindowsSystemDirectory called, which can always return to the true system directory on the terminal server. Application Stability Problem
Now, the stability of the application will now be discussed, these issues are derived from the changes that occur in Windows 2000, thereby discovering many errors that cause the application incompatibility in the implementation or detail of the application. However, what changes do will not destroy the application. Sometimes this problem occurs when the application runs rare in a rare manner.
Hard code path
The application generally uses the "hard code" reference method, so when Microsoft changes some parts of the system, the application will not work because of the content it wants to find, and the main culprit is the hardcode path. . On Windows 2000 or even Windows NT 4.0, many things are moved. For example, on the "My Documents" folder on Windows 9x is just a folder in the C disk or D disk root directory, namely:
/ My documents
Windows NT moves it, and puts its respective folders in the Windows system directory below for each user. So in the following examples, even if the folder is named "Personal", it is actually "My Documents" folder on Windows NT 4.0.
% WINDIR% / Profiles / Kylemar / Personal
WINDOWS 2000 moves again to the location of the folder, so that it is no longer located in the system directory or under the root of the root. Windows 2000 puts it:
/ Documents and Settings / Kylemar / My Documents
As you can see, when the folder changes, if the hard code is still acting in it, there will be an error. In fact, in the managed environment, the "My Documents" folder may also be on the network drive. In order to avoid this, it is necessary to use ShgetFolderPath like we have discussed before, and ensure this in Windows 95, Windows 98 or any platform. In the default Windows 2000 case, you can find the correct location.
Long file name and long printer name
Since Windows 95 came out, we have been talking about long file names and printer names. Initially, we just ask the application to support these two; after upgrading to Windows 2000, we ask for programs to support them correctly. We have found that in many places, the app does not implement correct support for long file names. But this is not to say that these applications do not support them (even if there is a small number), but we discover some errors in supporting long file names. For example, there is an application that claims to implement support for long file names, providing a buffer for all 256 characters. But when we remove files and provide a longer path to the lookup file (about 50 characters), the program has collapsed. This indicates that although the app tells us that it has a long buffer, it is actually only available to a shorter buffer. This is just a simple error in the application; since we transferred the "My Documents" folder to "Documents and Settings" instead of placing it in the root directory or Windows system directory, you will often encounter such errors. . The path has a tendency to grow, and the current average path length is 60 to 70 characters, and no longer 30 to 40 characters. The use of long path name is exposed to more and more errors. Another problem found in the "Documents and Settings" folder is "Documents and Settings" written by many applications, which cannot be accessed normally. The application analyzes the directory, as long as the word "documents" is found, the program will think that the end of "My Documents" is considered. In this way, the application will be interrupted, while thinking "I found the word 'Documents', I have found 'My Documents'." This is certain.
Be sure to fully check the long file name support function and test it. You will find a quite long string in the Windows 2000 application specification (http://msdn.microsoft.com/certification/appspec.asp (English)), you can use it to confirm if the application can support the length correctly file name.
Heap management
Another application stability problem is derived from the changes to the heap management on the Windows NT platform. This is the most shocking problem I mentioned here. It has great dangers that can lead to various issues in your application. It is actually the same as we often encounter in the old C language: a pointer error or memory usage error occurs. But it is difficult to handle one of the problems.
In fact, this problem starts from Windows NT 4.0, Service Pack 4. We have changed the heap manager to make it efficient, faster, especially for computers with multiprocessors. WINDOWS 2000 has changed on this basis, so that the program that can run on Windows NT 4.0 is unable to run after installing Service Pack 4. Or the program that can be run in Service Pack 4, cars in Windows 2000, because we have made a lot of improvements to the work of the heap manager. Obviously, if you need to improve system performance, and speed up the running speed of the heap manager, it is still much more. We did not make changes to the API itself, and we did not logically change the heap of work, but we have made some subtle changes in the repetition method of blocks, allowing the misconduct in the application to expose.
In short, what we do is as follows: Previously, when a block was released, it will be included in the unused empty block list, at the end of the table, and finally it will be filtered again. Now, we will cache the blocks that are last used and put them at the top of the table. When you need another block, you can first adjust this block first. If you need to call back a block, you will generate a space, you will call the block just used, so you can keep yourself on the same page and improve the speed of the system. This is what we have encountered in C language design and C program development from the beginning. In fact, there is no way to better find these problems. You can use some business tools to find these questions. In addition, you need to test these software as much as possible on Windows 2000.
We have found that many applications have a pile of problems. The most common problem is to try to access the released memory. The result is that the application will allocate, which will read and write these blocks, then release these blocks, and then read and write these blocks. The danger of this practice is that the data is destroyed, and your app will crash. But because it resides in a piece or page that has been dominated, and because you are reading and writing blocks that allow you to write, it will not cause access to violation, but cause data damage. I am willing to lead to system crash, because this situation is easier to remedy, but it is difficult to say that any case may happen.
Another problem is: In order to get a more fully utilization of a page, the Windows 2000 and Service Pack 4 may also move this allocation area when you have reassigned a smaller block. . Many developers hold a suspicious optimization point. "If I reassign a smaller block than I specified by I originally specified, no one can point my pointer to me, I can redistribute, and believe it is no longer Moving pointer. Therefore, as long as I make it smaller, no one can move it. " This will result in a comprehensive error.
Call rule
The call rule issue is discussed below. In addition, you must use stdcall for all window procedures. Unfortunately, we have found that many applications do not use stdcall for its window, and the dialog process is also true. If you don't use stdcall, your program may not work properly. In Windows 95 and Windows 98, you can avoid this problem by using a C_DECL rule; in other words, if you only forgetting the C_DECL rule during the window, the system will not collapse.
We set a ribbon for this in Windows 2000, so we can capture them as much as possible. However, in the last week, I still found a mistake. It jumped out to me, "Yes, we have made these handles in place, and we try to handle standard calls, but because applications are not used Standard calls, we still have not intercepted them correctly. "If your window uses stdcall instead of other call rules, things will be much simpler.
We also found that some applications use the correct call rules, but not properly implemented, or the error in the compiler shows that there is no correct use of call rules, or the application will enter the registration process faster. Because we are carrying out further optimization, the purpose is to use registration content more stringent and make it less resources, run faster, and we have encountered many cases where applications are not compatible due to failure to strictly follow rules.
Non-buffered file file I / O
If you want to handle some file I / O without using the buffer provided by the system, you need to use the flag on create file file_flag_no_buffering (meaning, you can provide buffers yourself without using the system assigned to these read and write operations. ). You must confirm that the buffer passed to the ReadFile and WriteFile API has been properly aligned for the device. These have no difference in previous, however, we found that these alignment is slightly different on Windows 2000, especially in support for new ELTRA 66 IDE drives. So, you must confirm that the allocation buffer is correct. The easiest way to achieve this is to use Virtualalloc. Virtualalloc will always be aligned with the buffer, so it can always be correctly aligned regardless of the buffer size required by the device completion file I / O. Remember, when you do this, you must confirm that you are using a few times of the actual sector size of the I / O device when you read and write. You can get the sector size via GetDiskFreespace and make sure you only assign and read several times the size of these sectors. Large drive
Another problem related to the drive is to have some large drives. Obviously, the current drive is much larger than 4GB, in general, the available space is much more than 4GB. However, if you use getDiskFreespace, it will return a string of 32-bit values, which is not accurate, because the actual value is much more than, this situation will appear in many places. We have found that the number of disk space returned by the application is negative, thereby appearing a variety of problems.
You need to apply GetDiskFreespaceEx, which uses ularge_integer_ instead of int, so you can provide you with real data for available space.
Open another HKEY_CURRENT_USER
Some applications (especially some server applications) require information from other HKEY_CURRENT_USERs instead of their initial or current HKEY_CURRENT_USER. The problem is that the way HKEY_CURRENT_USER actually used is based on each process. The application will try to close HKEY_CURRENT_USER, simulate new users, then open HKEY_CURRENT_USER, and hope that they get the correct HKEY_CURRENT_USER. The problem is if this operation is performed using multiple threads, one of the threads may have been completed, and the other thread may be in the operation. You can't figure out which HKEY_CURRENT_USER is ending because the system will declare the second open "" I have opened HKEY_CURRENT_USER, I used the one in the cache. "This operation has quite dangerous. In order to improve this situation, we have added a new, named RegOpenCurrentuser, with this API, you can implement an analog process correctly to get the true hkey_current_user.
Check bit (BIT) logo
Another low-level C class problem: We have found that an application is checked when a bit flag is checked, rather than actually checking if a particular bit is present. We will add a flag in all versions of Windows 2000 and Windows 2000, so you need to make sure you check the bit, not whether it is equal. We have added owner graphics that do not focus values and acceleration values, so that they have different types of drawing parameters. The following is the way to check the bit mark:
The order of if (fitemstate & ods_focus) message
We have been telling developers to express some specific meaning or rely on the order of messages or rely on the order of the application to receive messages. This is reliable. We even discover some applications depend on the order of messages in some multi-threaded applications. For example, it may happen: there is a thread to turn off, then a message is issued to the main message, then the other thread is turned off, and a message is issued. The application may send the message to the order of threads. We have changed the operation of the thread plan program. Ideally, they complete the release of the message, will send the message to the queue in order to process, but the actual situation is not. If you try it, it will find that the order of the message is inconsistent with the order of thread off, thereby various issues. Also emphasized, if you need to rely on the order of the message (especially in the case of cross thread), you don't want to think that the message itself is a synchronization method, and add your own synchronization mechanism.
Multiple monitors
Starting with Windows 98, Windows has the ability to handle multiple monitors. Windows 2000 is the first platform with this ability, Windows NT-based platform. A big problem: You must confirm that your application can correctly handle the negative coordinates and oversized coordinates or behave as oversized coordinates. If multiple monitors are set, the main monitor is on the right side of the sub-monitor, the deputy monitor will be completely in the negative coordinate area. If your application calls a window that should be in the deputy monitor, the application wants to maximize the window, assume that the application cannot handle the multi-monitor system correctly, which will move the window throughout the window due to the current coordinates Main display. This should not occur. If you need a positioning window, you must test the application in the multi-display system, confirm that these negative coordinates can be handled correctly. This should be processed so for a large-scale coordinate. You need to use the new system target shown in the figure to ensure that the window is placed at its location.
Difference between Windows platforms
I will discuss the last type of problem (more than other issues): The basic difference between the Windows platform. Windows 2000 is based on WinSows NT. We recognize that a large number of users will upgrade their Windows 9x to Windows 2000. We have been testing some applications, move them from Windows 9x to the Windows 2000 platform. You will find a lot of information about this issue in the magazine article and SDK. You need to make sure your app is not closely to the Windows 9x platform, but it should be closely to the Windows NT platform.
Applications with strict restrictions
The first target strict restriction is that the API used by the application can only be implemented on the Windows 9x platform, and cannot be implemented in Windows NT. The Tool Help API I often use is an example. In Windows 2000 we can already support Tool Help API to some extent, but you will find that there is a large number of APIs in Windows 9x have not found the way to upgrade to Windows NT. There is no truly possible way to solve this problem. You can use the .csv file in the SDK, this file is actually just a spreadsheet, which tells you about any API: Where can be implemented, where is it, how to work, in addition to this other information. Another way is to effectively test the application to ensure that your application can be migrated between Windows 98 and Windows NT platforms to ensure they can run. This method may be much simpler, and it is much better.
You need to pay attention to the following facts; the Windows NT platform uses a full 32-bit coordinate system in its GDI call, while Windows 9x is 16 bits. Be sure to know these differences. In fact, all the handles in Windows NT are completely 32 bits. Some developers tried to take advantage of the following facts: The handle in Windows 9x is 32 bits, but only 16 bits. If you use this on Windows NT, the consequences will be very bad. General replacement
There are many applications that have many applications in the application replacement process will also fall into dysfunction. The way Windows 9x can be called "Flat Thunk": it allows 16-bit applications to transfer 32-bit applications, allowing 32-bit applications to be transferred directly into a 16-bit component, or 16-bit applications program. Windows 2000 does not support this feature, especially without supporting 32-bit applications directly to 16-bit applications. Ways used in Windows 2000 and Windows NT can be called "generic tunk": General Replacement allows 16-bit applications to be transferred to 32-bit components, and the 16-bit application is allowed to initiate a calling process for 32-bit components, Then call the 16-bit application by 32-bit components without supporting 16-bit components directly from 32-bit code, which cannot take effect. You can only start the 32-bit call from 16 bits, which cannot be seen. In addition, it is necessary to remember a point for the replacement process: the basic process model between Windows 9X and Windows NT is different. You can see some differences from a general replacement. The easiest way is to transplant 16-bit components to 32-bit components. You need to have a clear understanding of the replacement of these two platforms.
