windbg

WDK에 있음. WDK 다운받고 kisetup 실행 windows debugging tools 선택

#pragma

14.6. The #pragma Directive The #pragma directive is a standard way to provide additional information to the compiler. This directive has the following form: #pragma [tokens] If the first token after #pragma is STDC, then the directive is a standard pragma. If not, then the effect of the #pragma directive is implementation-dependent. For the sake of portability, you should use #pragma directives sparingly. If the preprocessor recognizes the specified tokens, it performs whatever action they stand for, or passes information on to the compiler. If the preprocessor doesn't recognize the tokens, it must ignore the #pragma directive. Recent versions of the GNU C compiler and Microsoft's Visual C compiler both recognize the pragma pack(n), for example, which instructs the compiler to align structure members on certain byte boundaries. The following example uses pack(1) to specify that each structure member be aligned on a byte boundary: #if defined( _ _GNUC_ _ ) || defined( _MSC_VER ) #pragma pack(1) // Byte-aligned: no padding. #endif Single-byte alignment ensures that there are no gaps between the members of a structure. The argument n in a pack pragma is usually a small power of two. For example, pack(2) aligns structure members on even-numbered byte addresses, and pack(4) on four-byte boundaries. pack( ) with no arguments resets the alignment to the implementation's default value. C99 introduced the following three standard pragmas: #pragma STDC FP_CONTRACT on_off_switch #pragma STDC FENV_ACCESS on_off_switch #pragma STDC CX_LIMITED_RANGE on_off_switch The value of the on_off_switch must be ON, OFF, or DEFAULT. The effects of these pragmas are discussed in "Mathematical Functions" in Chapter 16.

[win32api] icon

change NULL into hInstance

 char szAppName[] ="해구장"; 
 WndClass.style = NULL; 
 WndClass.lpfnWndProc = WndProc; 
 WndClass.cbClsExtra = 0; 
 WndClass.cbWndExtra = 0; 
 WndClass.hInstance = hInstance; 
 WndClass.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_ICON2)); 
 WndClass.hCursor = LoadCursor(NULL, IDC_ARROW); 
 WndClass.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH); 
 WndClass.lpszMenuName = NULL; 
 WndClass.lpszClassName = szAppName;

[win32api] read file

 HANDLE hFile = CreateFile(szFileName, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
 if (hFile != INVALID_HANDLE_VALUE)
 {
  // Get text length of data in editbox
  DWORD dwTextLength = GetWindowTextLength(GetDlgItem(hWnd, editID));
  if (dwTextLength > 0)
  {
   char* pszRead;
   DWORD dwBufferSize = dwTextLength + 1; // + 1 because NULL character needed (\0)

   pszRead = (char*)malloc(dwBufferSize);
   // Read text from editbox
   if (GetWindowText(GetDlgItem(hWnd, editID), pszRead, dwBufferSize))
   {
    DWORD dwWritten;

    WriteFile(hFile, pszRead, dwTextLength, &dwWritten, NULL);
    bSaved = TRUE;
   }
   free(pszRead);
  }

  CloseHandle(hFile);

[r]install package

>install.packages("MCMCpack")

[asm] int 21h

http://mongmio.tistory.com/12

[asm]FCB

A File Control Block (FCB) is a file system structure in which the state of an open file is maintained. An FCB is managed by the operating sytem, but it resides in the memory of the program that uses the file, not in operating system memory. This allows a program to have as many files open at one time as it wants to, provided it can spare enough memory for an FCB per file.

The FCB originates from CP/M and is also present in most variants of DOS, though only as a backwards compatibility measure in MS-DOS versions 2.0 and later. A full FCB is 36 bytes long; in early versions of CP/M, it was 33 bytes. This fixed size, which could not be increased without breaking application compatibility, lead to the FCB's eventual demise as the standard method of accessing files.

The meanings of several of the fields in the FCB differ between CP/M and MS-DOS, and also depending on what operation is being performed. The following fields have consistent meanings:

Offset	Byte size	Contents
00	1	Drive number — 0 for default, 1 for A:, 2 for B:,...
01	8	File name and file type — together these form a 8.3 file name
09	3
0C	20	Implementation dependent — should be initialised to zero before the FCB is opened.
20	1	Record number in the current section of the file — used when performingsequential access.
21	3	Record number to use when performing random access.

[edit]Usage

In CP/M and MS-DOS 1 (which did not include support for subdirectories), the FCB was the only method of accessing files. When subdirectories were introduced in MS-DOS 2, FCBs proved too small to handle the extra data required for that, and thus were superseded by file handles, as used on UNIX and its derivatives. File handles are simply consecutive integer numbers associated with specific open files.

If a program uses the newer file handle API to open a file, the operating system will manage its internal data structure associated with that file in its own memory area. This has the great advantage that these structures can grow in size in later operating system versions without breaking compatibility with application programs; its disadvantage is that, given the rather simplistic memory management of MS-DOS and its compatibles, space for as many of these structures as the most "file-hungry" program is likely to use has to be reserved at boot time and cannot be used for any other purpose while the computer is running. Such memory reservation is done using the FILES= command in the CONFIG.SYS file. This problem does not occur with FCBs in DOS 1 or in CP/M, since the operating system stores all that it needs to know about an open file inside the FCB and thus does not need to use any per-file memory in operating system memory space. When using FCBs in MS-DOS 2 or later, the FCBs are dummies that store references to the actual file management data in operating system memory. Because of this, the number of FCBs which can be kept open at once in DOS 2 or higher is limited as well, usually to 4; using the FCBS= command in the CONFIG.SYS file, it may be increased beyond that number if necessary.

FCBs were supported in all versions of MS-DOS and Windows until the introduction of theFAT32 filesystem. Windows 95, Windows 98 and Windows Me do not support the use of FCBs on FAT32 drives, except to read the volume label. This caused some old DOS applications, including Wordstar, to fail under these versions of Windows.

The FCB interface does not work properly on Windows NT, 2000, etc. either - WordStar does not function properly on these operating systems. DOS emulators DOSEMU and DOSBoximplement the FCB interface properly, thus they are a way to run older DOS programs that need FCBs on modern operating systems.

[edit]External links