Блог GunSmoker-а

Используется ли файл?

2012-02-19T15:35:00.000+04:00

Это перевод Is File In Use. Автор: Christian Wimmer.

На форумах DelphiPraxis задали вопрос, который обычно всплывает несколько раз в год. Однако в этот раз я мог сказать, что появился API, который решает эту проблему. Вопрос был о том, как определить, кто держит файл. Главной проблемой стало то, что я никак не мог вспомнить название API, так что Assarbad пришлось постараться и поискать его.

И это имя - IFileIsInUse, интерфейс. Он объявлен в Shobjidl.h, Shobjidl.idl и, сейчас уже, в JwaShlObj.pas. Вот вырезка кода:

{$IFDEF WINVISTA_UP}
const
  IID_IFileIsInUse: TGUID = (
    D1:$64a1cbf0; D2:$3a1a; D3:$4461; D4:($91,$58,$37,$69,$69,$69,$39,$50));

type
  {$ALIGN 4}
  tagFILE_USAGE_TYPE = (
    FUT_PLAYING = 0,
    FUT_EDITING = 1,
    FUT_GENERIC = 2
  );
  FILE_USAGE_TYPE = tagFILE_USAGE_TYPE;
  TFileUsageType = FILE_USAGE_TYPE;

const
  OF_CAP_CANSWITCHTO     = $0001;
  OF_CAP_CANCLOSE        = $0002;

type
  IFileIsInUse = interface(IUnknown)
    ['{64a1cbf0-3a1a-4461-9158-376969693950}']
    function GetAppName(out ppszName: LPWSTR) : HRESULT; stdcall;
    function GetUsage(out pfut : FILE_USAGE_TYPE) : HRESULT; stdcall;
    function GetCapabilities(out pdwCapFlags : DWORD) : HRESULT; stdcall;
    function GetSwitchToHWND(out phwnd : HWND) : HRESULT; stdcall;
    function CloseFile() : HRESULT; stdcall;
  end;

{$ENDIF WINVISTA_UP}

Интерфейс может использоваться двояко - и клиентом и быть реализованным сервером. Клиент обычно проверяет, заблокирован ли файл, и получает ссылку на интерфейс для вызова его методов. Сервер же может держать блокировку на файле и реализовывать этот интерфейс, чтобы предоставить его услуги клиенту. Эта статья коснётся только стороны клиента.

Вы увидите, что этот API будет работать только если обе стороны выполняют свою работу. Процесс, блокирующий файл, также должен реализовать этот интерфейс и зарегистрировать его, чтобы клиент мог получать информацию. Нет никакой прямой связи между блокировкой файла и именем процесса. Если процесс держит блокировку на файл, но не реализует интерфейс, то вы снова оказываетесь сами за себя.

В конечном итоге, это просто помощник Оболочки для красивого диалога удаления файлов Windows:

Итак, напомню вид самого интерфейса:

IFileIsInUse = interface(IUnknown)
  function GetAppName(out ppszName: LPWSTR) : HRESULT; stdcall;
  function GetUsage(out pfut : FILE_USAGE_TYPE) : HRESULT; stdcall;
  function GetCapabilities(out pdwCapFlags : DWORD) : HRESULT; stdcall;
  function GetSwitchToHWND(out phwnd : HWND) : HRESULT; stdcall;
  function CloseFile() : HRESULT; stdcall;
end;

Методы интерфейса достаточно просто понять:

GetAppName получает имя процесса, который держит файл. Это будет произвольное имя, выбранное самим приложением. Всегда используйте PWideChar для получения имени и не забывайте освободить память с помощью CoTaskMemFree (или через IMalloc). Не забывайте проверять результат вызова. Если вам нравятся исключения, то вы можете изменить прототип метода на safecall.
GetUsage возвращает причину блокировки файла. Это может быть одна из констант в перечислении TFileUsage. Это может быть проигрывание видео, музыки или редактирование файла. Либо же это может быть общая причина FUT_GENERIC. Возможно, в будущем будет добавлено больше кодов.
GetCapabilities возвращает набор флагов. Они указывают, можно ли попросить закрыть файл вызовом CloseFile (OF_CAP_CANCLOSE) или же мы можем активировать приложение, блокирующее файл (OF_CAP_CANSWITCHTO). Лучше всего уведомить пользователя о переключении окон, иначе он может сильно расстроиться из-за внезапно пропавшего окна вашего приложения. Само переключение окон можно сделать вызовом SetForegroundWindow. Но для успешности выполнения этой операции ваше приложение должно иметь фокус.
GetSwitchToHWND возвращает описатель окна процесса, блокирующего файл. Используйте этот описатель только для переключения на окно. Вы понятия не имеете, что за окно вам могут тут вернуть. Не нужно пытаться его закрыть или делать что-то ещё - это просто будет плохим поведением. И всегда проверяйте на ошибки вызова. Иначе вы не узнаете, вернули ли вам корректный описатель.

Конечно же, вы можете вызывать этот метод только если вызов GetCapabilities вернул бит OF_CAP_CANSWITCHTO.
CloseFile просит сервер закрыть файл. Вы можете вызывать этот метод только если вызов GetCapabilities вернул бит OF_CAP_CANCLOSE. Ну, это действительно приятная возможность. Но не доверяйте ей слепо! Всегда перепроверьте блокировку файла после вызова прежде чем двигаться дальше.

Чтобы получить интерфейс для файла вам нужно сначала иметь заблокированный файл. Вы можете скачать и скомпилировать пример из MSDN с именем IsFileInUse или вы можете просто открыть файл в приложении, которое реализует такие интерфейсы (например, MS Office).

Следующий шаг - узнать, где размещаются заблокированные файлы. Это место - running object table, или ROT для краткости (её можно получить через ActiveX.GetRunningObjectTable()). Это глобальная* (для машины) таблица, которая хранит запущенные (running) COM объекты. Вы можете реализовать свой собственный интерфейс и поместить его в эту таблицу. Поскольку интерфейсы могут быть произвольными, к ним прикрепляются моникеры (IMoniker), которые уникально их описывают. Существует несколько типов моникеров вроде класса (class), элемента (item) и файла (file) - и нас интересует только последний тип.

Так что вся работа будет заключаться в переборе моникеров в ROT. Обычно их там не много (у меня было всего 5). Каждый моникер проверяется на тип (IsSystemMoniker) и то, является ли он файловым моникером (MKSYS_FILEMONIKER), а затем путь к файлу сравнивается с нашим файлом. Если честно, то я не могу сказать, зачем пример сперва сравнивает префикс, а потом сам моникер - извините.

Сам объект получается по моникеру через вызов GetObject у ROT. Этот вызов может завершиться с ошибкой E_ACCESS_DENIED, так что проверяйте на ошибки. В итоге мы получаем интерфейс IFileIsInUse. Поскольку файл мог быть зарегистрирован без реализации этого интерфейса, то нам снова нужна проверка на ошибки.

Я не писал весь этот код сам. Фактически, я взял за основу уже упоминавшийся мною пример из MSDN.

function GetFileInUseInfo(const FileName : WideString) : IFileIsInUse;
var
  ROT : IRunningObjectTable;
  mFile, enumIndex, Prefix : IMoniker;
  enumMoniker : IEnumMoniker;
  MonikerType : LongInt;
  unkInt  : IInterface;
begin
  result := nil;

  OleCheck(GetRunningObjectTable(0, ROT));
  OleCheck(CreateFileMoniker(PWideChar(FileName), mFile));

  OleCheck(ROT.EnumRunning(enumMoniker));

  while (enumMoniker.Next(1, enumIndex, nil) = S_OK) do
  begin
    OleCheck(enumIndex.IsSystemMoniker(MonikerType));
    if MonikerType = MKSYS_FILEMONIKER then
    begin
      if Succeeded(mFile.CommonPrefixWith(enumIndex, Prefix)) and
         (mFile.IsEqual(Prefix) = S_OK) then
      begin
       if Succeeded(ROT.GetObject(enumIndex, unkInt)) then
        begin
          if Succeeded(unkInt.QueryInterface(IID_IFileIsInUse, result)) then
          begin
            result := unkInt as IFileIsInUse;
            exit;
          end;
        end;
      end;
    end;
  end;
end;

Заключение

В целом этот API имеет такие недостатки:

Этот API рассчитывает на то, что программа, заблокировавшая файл, реализует и зарегистрирует специальный интерфейс. Если же приложение не озаботится этой задачей, то вы не сможете использовать этот метод.
Если вы заблокируете файл на разделяемой сетевой папке, а затем попробуете обратиться к нему по локальному имени, то не сможете определить процесс, заблокировавший файл. Причина кроется в самой Windows. Windows является провайдером файлов внешнему миру (даже если это всего лишь петля обратно на локальную машину), так что Проводник Windows покажет просто "Система" в качестве блокиратора. Также, в ROT вы увидите только сетевой (UNC) путь вместо локального.
(*) Примечание безопасности: ROT не является по настоящему глобальной. Фактически, в системе есть несколько ROT. ROT делятся индивидуально по пользователям, а затем по mandatory integrity control (MIC) или integrity levels (IL) - высокому (high), среднему (medium) и, вероятно, низкому (low) (я не проверял). Если вы запущены как обычный пользователь, ваши процессы будут иметь средний уровень, а процессы администратора - высокий. Программа со средним уровнем сможет зарегистрировать себя только в ROT для среднего уровня. Поэтому, если она хочет создать ключи реестра для COM (LOCAL_MACHINE\Classes\AppID\guid), то ей нужно запуститься под администратором хотя бы раз. Таким образом, она сможет стать видимой для всех ROT при желании. К сожалению, это ещё не всё. На многопользовательской системе каждый объект в моникере имеет дескриптор безопасности, который говорит COM, кто имеет к нему доступ. Если Алиса хочет получить доступ к ROT, созданной Бобом, то Боб должен явно разрешить Алисе доступ к ней. Как обычно в вопросах безопасности, по умолчанию доступ разрешается только системе, администраторам и создателю - эти настройки копируются из глобальных настроек безопасности COM и они могут быть изменены либо в реестре для AppID при запуске процесса, либо для каждого регистрируемого объекта сервером. JWSCL даёт доступ к обоим вариантам в файле JwsclComSecurity.pas (>= 0.9.4). И таким образом сервер может изменить настройки, чтобы, скажем, дать всем прошедшим проверку пользователям доступ к объекту.

Пример

Вы можете скачать файл-пример напрямую с Subversion:
https://jedi-apilib.svn.sourceforge.net/svnroot/jedi-apilib/jwapi/trunk/Examples/FileIsInUse/Client/FileIsInUseClientExample.dpr

См. также: Как мне найти программу, которая держит этот файл?

Как мне найти программу, которая держит этот файл?

2012-02-18T05:33:00.000+04:00

Это перевод How do I find out which process has a file open? Автор: Реймонд Чен.

Исторически, нет никакого специального способа найти процесс, который держит файл. Файловый объект имеет обычный счётчик ссылок объекта ядра и когда счётчик опускается до нуля - файл закрывается. Но в системе никто не отслеживает процессы, открывшие данный описатель, и сколько именно раз они его открыли (и это упрощённое изложение даже игнорирует тот факт, что счётчик может быть увеличен вовсе не процессом, а, скажем, драйвером режима ядра; или, быть может, изначально счётчик был увеличен процессом, который теперь уже закрыт, но файл ещё держится драйвером ядра).

Это состояние вещей согласуется с концепцией не хранить информацию, которая вам не нужна. Файловую систему не заботит, кто там держит её файлы. Её задача - закрыть файл, когда уйдёт последняя ссылка.

Аналогичную ситуацию вы видите в COM. Всё, что вас заботит - когда же счётчик опустится до нуля (потому что в этот момент вам нужно удалить объект). Если позже вы обнаружите в своём процессе утечку, то у вас нет никакого волшебного запроса "Покажи мне всех, то вызывал _AddRef для моего объекта" - просто потому, что вы никогда и не вели учёт вызывающих _AddRef. Нет у вас и возможности сделать так: "Вот объект, который я хочу удалить. Покажи мне всех использующих его, так что я смогу их удалить".

По крайней мере таким был классический сценарий.

А теперь познакомьтесь с Restart Manager.

Официальная цель Restart Manager - оказать помощь в закрытии и перезапуске приложений, которые вы хотите обновить. Чтобы сделать это, вам нужно отслеживать, какие процессы держат ссылки и на какие файлы. И вот она та самая база данных, что нам нужна (почему это ядро хранит список процессов, открывших файл? Потому что это принцип, обратный к принципу не хранить вещи, которые вам не нужны: теперь ядру нужна эта информация!)

Вот простая программа, которая принимает в командной строке имя файла и показывает список процессов, открывших этот файл.

program Project78;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  Winapi.Windows,
  System.SysUtils;

{$A+,Z4}

const
  PROCESS_QUERY_LIMITED_INFORMATION = $1000;

  RstrtMgr = 'Rstrtmgr.dll';

  RM_SESSION_KEY_LEN = SizeOf(TGUID);          // RM_SESSION_KEY_LEN - size in bytes of binary session key
  CCH_RM_SESSION_KEY = RM_SESSION_KEY_LEN * 2; // CCH_RM_SESSION_KEY - character count of text-encoded session key
  CCH_RM_MAX_APP_NAME = 255;                   // CCH_RM_MAX_APP_NAME - maximum character count of application friendly name
  CCH_RM_MAX_SVC_NAME = 63;                    // CCH_RM_MAX_SVC_NAME - maximum character count of service short name
  RM_INVALID_TS_SESSION = -1;                  // Uninitialized value for TS Session ID
  RM_INVALID_PROCESS = -1;                     // Uninitialized value for Process ID

type
  TAppName = array[0..CCH_RM_MAX_APP_NAME] of WideChar;
  TServiceName = array[0..CCH_RM_MAX_SVC_NAME] of WideChar;
  TSessionKey = array[0..CCH_RM_SESSION_KEY] of WideChar;

  _RM_APP_TYPE = (
    RmUnknownApp = 0,   // Application type cannot be classified in known categories
    RmMainWindow = 1,   // Application is a windows application that displays a top-level window
    RmOtherWindow = 2,  // Application is a windows app but does not display a top-level window
    RmService = 3,      // Application is an NT service
    RmExplorer = 4,     // Application is Explorer
    RmConsole = 5,      // Application is Console application
    RmCritical = 1000   // Application is critical system process where a reboot is required to restart
  );
  RM_APP_TYPE = _RM_APP_TYPE;
  TRMAppType = RM_APP_TYPE;

  _RM_SHUTDOWN_TYPE = (
    RmForceShutdown = $1,          // Force app shutdown
    RmShutdownOnlyRegistered = $10 // Only shudown apps if all apps registered for restart
  );
  RM_SHUTDOWN_TYPE = _RM_SHUTDOWN_TYPE;
  TRMShutdownType = RM_SHUTDOWN_TYPE;

  _RM_APP_STATUS = (
    RmStatusUnknown = $0,          // Application in unknown state or state not important
    RmStatusRunning = $1,          // Application is currently running
    RmStatusStopped = $2,          // Application stopped by Restart Manager
    RmStatusStoppedOther = $4,     // Application detected stopped by outside action
    RmStatusRestarted = $8,        // Application restarted by Restart Manager
    RmStatusErrorOnStop = $10,     // An error occurred when stopping this application
    RmStatusErrorOnRestart = $20,  // An error occurred when restarting this application
    RmStatusShutdownMasked = $40,  // Shutdown action masked by filer
    RmStatusRestartMasked = $80    // Restart action masked by filter
  );
  RM_APP_STATUS = _RM_APP_STATUS;
  TRMAppStatus = RM_APP_STATUS;

  _RM_REBOOT_REASON = (
    RmRebootReasonNone = $0,               // Reboot not required
    RmRebootReasonPermissionDenied = $1,   // Current user does not have permission to shut down one or more detected processes
    RmRebootReasonSessionMismatch = $2,    // One or more processes are running in another TS session.
    RmRebootReasonCriticalProcess = $4,    // A critical process has been detected
    RmRebootReasonCriticalService = $8,    // A critical service has been detected
    RmRebootReasonDetectedSelf = $10       // The current process has been detected
  );
  RM_REBOOT_REASON = _RM_REBOOT_REASON;
  TRMRebootReason = RM_REBOOT_REASON;

  _RM_UNIQUE_PROCESS = record
    dwProcessId: DWORD;               // PID
    ProcessStartTime: TFileTime;      // Process creation time
  end;
  RM_UNIQUE_PROCESS = _RM_UNIQUE_PROCESS;
  PRM_UNIQUE_PROCESS = ^_RM_UNIQUE_PROCESS;
  TRMUniqueProcess = RM_UNIQUE_PROCESS;
  PRMUniqueProcess = PRM_UNIQUE_PROCESS;

  _RM_PROCESS_INFO = record
    Process: TRMUniqueProcess;         // Unique process identification
    strAppName: TAppName;              // Application friendly name
    strServiceShortName: TServiceName; // Service short name, if applicable
    ApplicationType: TRMAppType;       // Application type
    AppStatus: ULONG;                  // Bit mask of application status
    TSSessionId: DWORD;                // Terminal Service session ID of process (-1 if n/a)
    bRestartable: BOOL;                // Is application restartable?
  end;
  RM_PROCESS_INFO = _RM_PROCESS_INFO;
  PRM_PROCESS_INFO = ^_RM_PROCESS_INFO;
  TRMProcessInfo = RM_PROCESS_INFO;
  PRMProcessInfo = PRM_PROCESS_INFO;

function QueryFullProcessImageName(hProcess: THandle; dwFlags: DWORD; lpExeName: PChar; var lpdwSize: Integer): BOOL; stdcall; external kernel32 name {$IFDEF UNICODE}'QueryFullProcessImageNameW'{$ELSE}'QueryFullProcessImageNameA'{$ENDIF};

function RmStartSession(out pSessionHandle: DWORD; dwSessionFlags: DWORD; out strSessionKey: TSessionKey): DWORD; stdcall; external RstrtMgr;
function RmEndSession(dwSessionHandle: DWORD): DWORD; stdcall; external RstrtMgr;
function RmRegisterResources(dwSessionHandle: DWORD; nFiles: UINT; rgsFileNames: PPWideChar; nApplications: UINT; rgApplications: PRMUniqueProcess; nServices: UINT; rgsServiceNames: PPWideChar): DWORD; stdcall; external RstrtMgr;
function RmGetList(dwSessionHandle: DWORD; out pnProcInfoNeeded: UINT; var pnProcInfo: UINT; out rgAffectedApps: TRMProcessInfo; out lpdwRebootReasons: DWORD): DWORD; stdcall; external RstrtMgr;

procedure Run;

  function StrFromAppType(const AAppType: TRMAppType): String;
  begin
    case AAppType of
      RmMainWindow:  Result := 'Application is a windows application that displays a top-level window';
      RmOtherWindow: Result := 'Application is a windows app but does not display a top-level window';
      RmService:     Result := 'Application is an NT service';
      RmExplorer:    Result := 'Application is Explorer';
      RmConsole:     Result := 'Application is Console application';
      RmCritical:    Result := 'Application is critical system process where a reboot is required to restart';
    else
                     Result := 'Application type cannot be classified in known categories';
    end;
  end;

const
  Num = 10;
var
  dwSession: DWORD;
  szSessionKey: TSessionKey;
  pszFile: PPWideChar;
  P: PWideChar;
  FileName: WideString;
  dwReason: DWORD;
  i: Integer;
  nProcInfoNeeded: UINT;
  nProcInfo: UINT;
  rgpi: array[0..Num - 1] of TRMProcessInfo;
  hProcess: THandle;
  ftCreate, ftExit, ftKernel, ftUser: TFileTime;
  sz: String;
  cch: Integer;
begin
  FileName := ParamStr(1);

  FillChar(SessionKey, SizeOf(SessionKey), 0);
  SetLastError(RmStartSession(dwSession, 0, szSessionKey));
  Win32Check(GetLastError = ERROR_SUCCESS);
  try
    P := PWideChar(FileName);
    pszFile := @P;
    SetLastError(RmRegisterResources(dwSession, 1, pszFile, 0, nil, 0, nil));
    Win32Check(GetLastError = ERROR_SUCCESS);

    nProcInfo := Num;
    SetLastError(RmGetList(dwSession, nProcInfoNeeded, nProcInfo, rgpi[0], dwReason));
    Win32Check(GetLastError = ERROR_SUCCESS);

    for i := 0 to nProcInfo - 1 do
    begin
      WriteLn(Format('%d.ApplicationType = %d (%s)', [i, Ord(rgpi[i].ApplicationType), StrFromAppType(rgpi[i].ApplicationType)]));
      WriteLn(Format('%d.strAppName = %s', [i, rgpi[i].strAppName]));
      WriteLn(Format('%d.Process.dwProcessId = %d', [i, rgpi[i].Process.dwProcessId]));

      hProcess := OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, False, rgpi[i].Process.dwProcessId);
      if hProcess <> 0 then
      try
        if GetProcessTimes(hProcess, ftCreate, ftExit, ftKernel, ftUser) and
           (CompareFileTime(rgpi[i].Process.ProcessStartTime, ftCreate) = 0) then
        begin
          cch := MAX_PATH;
          SetLength(sz, cch);
          if QueryFullProcessImageName(hProcess, 0, PChar(sz), cch) and
             (cch <= MAX_PATH) then
          begin
            SetLength(sz, cch);
            WriteLn(Format('%d.Process.Name = %s', [i, sz]));
          end;
        end;
      finally
        CloseHandle(hProcess);
      end;
      WriteLn;
    end;
  finally
    RmEndSession(dwSession);
  end;
end;

begin
  try
    if ParamCount = 0 then
      Exit;
    Run;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Итак, первой строкой в этом коде... нет, постойте - ещё до вызова функции RmStartSession у нас есть строка

FillChar(SessionKey, SizeOf(SessionKey), 0);

Одна эта строка кода решает аж два бага!

Первый из них - баг в документации. Документация по функции RmStartSession не указывает, насколько большим должен быть буфер для ключа сессии. Правильный ответ - CCH_RM_SESSION_KEY + 1.

Второй баг - в коде. Функция RmStartSession не завершает ключ терминатором, даже хотя прототип функции описан как возвращающий нуль-терминированную строку. Чтобы обойти эту проблему, мы очищаем буфер перед использованием, заполняя его нулями, так что то, что будет записано в ключ сессии, автоматически получит корректный терминатор (а именно - один из тех нулей, что мы записали).

Прим. пер.: при переводе с C на Delphi прототип функции был существенно изменён. Так что теперь ключ сессии передаётся как фиксированный массив.

Окей, эти проблемы ушли с дороги. Теперь, базовый алгоритм:

Создать сессию Restart Manager.
Добавить интересующий нас файл в сессию.
Запросить список процессов, влияющих на ресурс.
Напечатать немного информации по каждому процессу.
Закрыть сессию.

Я уже упомянул, что вы создаёте сессию вызовом RmStartSession. Следующим шагом мы добавляем в сессию единственный файл вызовом RmRegisterResources.

Теперь начинается веселье. Получение списка процессов обычно происходит в два этапа. Сначала вы запрашиваете число доступных процессов (передавая 0 в nProcInfo), затем выделяете память и вызываете функцию второй раз для получения данных. Но поскольку это просто пример, я вшил в программу фиксированное число процессов. Если файл открыт более 10 процессами, то я просто сдамся (вы можете проверить это, запустив программу и указав файл вроде kernel32.dll).

Прим.пер.: и если какой-то сильно умный читатель вздумает скопировать этот код и использовать "как есть"...

Вторая хитрая часть заключается в поиске процесса по TRMProcessInfo. Поскольку ID процессов могут использоваться заново (recycle), то структура TRMProcessInfo идентифицирует процесс комбинацией ID и времени его запуска. Такая комбинация является уникальной в рамках одной машины, потому что два процесса не могут иметь одинаковые ID в одно и то же время. Поэтому мы открываем процесс по его ID, а затем проверяем, что это именно тот процесс, что нам нужен (а если нет - то ID ссылается на процесс, который уже завершил работу с того момента, когда мы запрашивали список). Если же все данные совпали, то мы выводим путь к .exe файлу процесса.

Вот и всё, что нужно, чтобы перечислить все процессы, открывшие какой-то конкретный файл.

Конечно же, более выразительным интерфейсом для управления используемыми файлами является IFileIsInUse, который я упоминал не так давно. Этот интерфейс скажет вам не только какие приложения открыли файл (и в более дружелюбном формате, чем просто путь к .exe), но вы также сможете переключиться на это приложение и даже попросить его закрыть файл (если оно поддерживает эту возможность). Сама Windows 7 сначала пытается использовать IFileIsInUse, и лишь если он не сумел освободить файл - обращается к Restart Manager.

Читать далее: использование IFileIsInUse.

Некоторые папки двигать нельзя - и вам придётся научиться с этим жить

2012-02-17T03:52:00.000+04:00

Это перевод Some known folders cannot be moved, but others can, and you'll just have to accept that. Автор: Реймонд Чен.

Некоторые из "известных папок" оболочки (Shell known folders) могут быть помечены как KF_CATEGORY_FIXED, что делает их неперемещаемыми. И наоборот, если папка файловой системы не является "неподвижной", то она может быть перемещена.

Эта дихотомия представляется простой и недостойной отдельного обсуждения - за исключением того, что у некоторых клиентов иногда возникают проблемы включения этого понятия в своё мировоззрение.

У меня есть код, который вызывает SHSetFolderPath, и он работает для большинства папок, но для некоторых значений CSIDL вроде CSIDL_COMMON_APPDATA код завершается с ошибкой E_INVALIDARG. При этом не имеет значения, вызываю ли я его с повышением привилегий или нет. Что я делаю не так?

Разница в том, что CSIDL_COMMON_APPDATA (известная в Новом Мировом Порядке как FOLDERID_ProgramData) помечена как KF_CATEGORY_FIXED, так что её нельзя переместить.

А есть ли способ игнорировать флаг KF_CATEGORY_FIXED и переместить её?

Нет. Она неперемещаема. Извините. Вам просто остаётся принять тот факт, что эта папка не поменяет своё расположение по вашему желанию.

И буквально на следующий день мы получили такой вопрос от совершенно другого клиента:

У нас есть программа, которая следит за "известной папкой", но наш код вылетает, если пользователь меняет расположение папки в то время, пока программа за ней следит. Есть ли какой-нибудь способ сделать так, чтобы пользователь не мог двигать папку?

Если папка может быть перемещена, то вам нужно принять тот факт, что она может быть перемещена. Вы не можете изменить порядок вещей только потому, что это сделает легче жизнь лично вам.

Я нахожу любопытным, что мы получили два запроса подряд, которые просят о полностью противоположных вещах: "Я хочу сделать эту папку перемещаемой!" и "Я хочу сделать эту папку неперемещаемой!". Я могу только догадываться о том хаосе, который вызовут эти программы, будучи запущенными одновременно на одной машине!

Что может сделать программа - зарегистрировать IFileIsInUse для каталога, так что оболочка вызовет её, когда кто-то захочет переместить папку. И тогда, по крайней мере, программа будет знать, когда будут происходить страшные вещи, и подготовиться к ним. Мне сказали, что простой пример использования IFileIsInUse можно найти в SDK Windows 7 SDK в каталоге winui\Shell\AppPlatform\FileIsInUse. И ещё есть старая статья по этой теме в сейчас-уже-не-работающем блоге Shell Revealed.

Почему функция SetWindowsHookEx принимает параметр HINSTANCE?

2011-09-08T02:59:00.000+04:00

Это перевод Why does SetWindowsHookEx take an HINSTANCE parameter? Автор: Реймонд Чен.

Анонимный комментатор спросил, почему функция SetWindowsHookEx принимает параметр HINSTANCE, если она всё равно сконвертирует это значение в имя файла.

Потому что ловушки работали иначе в 16-битных Windows.

В мире 16-битных Windows не было такой вещи как внедрение ловушки. Все 16-битные приложения Windows работали в едином адресном пространстве, так что не было никакой необходимости внедрять ловушку - она и так была доступна всем процессам. Соответственно, не было никакой необходимости конвертировать описатель в имя файла.

Но что там с описателем? Он был нужен, чтобы увеличить счётчик загрузок модуля, чтобы модуль не выгрузился бы в то время, пока установлена и работает ловушка. Когда ловушка удалялась, то счётчик ссылок уменьшался.

И даже в 32-битных Windows оконному менеджеру всё ещё нужен описатель. Зачем? Чтобы сконвертировать адрес функции в DLL в RVA (прим.пер.: относительное смещение) - чтобы эту функцию можно было потом найти в DLL, когда она будет загружена в другой процесс (прим.пер.: и по другому адресу). Так что если бы вы передавали имя фала вместо описателя, то оконному менеджеру всё равно пришлось бы вызывать GetModuleHandle для получения описателя. Поскольку большинство программ хранит описатели, а не имена, то выбор параметра-описателя был естественным выбором (не говоря уже о сохранении совместимости с 16-битными Windows - а это очень важный критерий, когда ты пытаешься убедить людей писать программы под Win32).

Как злоупотребляли оконными ловушками в Win16

2011-09-07T02:55:00.000+04:00

Это перевод One way people abused hooks in 16-bit Windows. Автор: Реймонд Чен.

В прошлый раз мы увидели, как в 16-битных Windows реализуются оконные ловушки. Даже хотя значения HHOOK являются не прозрачными типами данных ("чёрным ящиком"), с которыми нужно работать как с описателями, многие программы "знали слишком много, чтобы стать опасными" - и воспользовались тем фактом, что значения HHOOK были просто указателями на предыдущую процедуру ловушки.

Самый частый способ использования этой информации во зло заключается в снятии ловушки неверным способом. Вместо вызова функции UnhookWindowsHook снова вызывалась SetWindowsHook! Более конкретно: текущая ловушка удалялась установкой на вершину цепочки предыдущей ловушки:

var
  g_hhkPrev: HHOOK;

// Установка ловушки
g_hhkPrev := SetWindowsHook(WH_KEYBOARD, MyHookProc);
...

// Безумие! Удаление ловушки установкой предыдущей ловушки "обратно"
SetWindowsHook(WH_KEYBOARD, g_hhkPrev);

Несмотря на это вопиюще неверное поведение, код работал; это вроде как две неверные вещи при сложении дали почти правильное. Если никто не трогал цепочку ловушек между установкой и таким "снятием" ловушки, то переустановка старой ловушки в вершину списка восстанавливала список ловушек в то же состояние, в которое он приходит при правильном удалении ловушки.

Но если между этими двумя вызовами кто-то другой установит их собственную ловушку, то установка старой ловушки заново приведёт к "удалению" не только MyHookProc, но и всех ловушек, которые были установлены после неё (это в точности та же проблема, которая получается, если вы неосторожно удаляете саб-классированные оконные процедуры).

Я до сих пор понятия не имею, почему кому-то взбрело в голову удалять ловушку именно таким способом вместо правильного - они ничего не сэкономили, а просто заменили одну строчку на другую:

UnhookWindowsHook(WH_KEYBOARD, MyHookProc);

Windows 3.1 ввела модель с SetWindowsHookEx/CallNextHookEx, которая не использовала технику внешнего связанного списка, а хранила список сама, внутренне. Это защитило цепочку ловушек от программ, которые портили её неверным управлением списком, но это также означало, что теперь все эти сумасшедшие программы, которые пытались удалить ловушку повторной установкой старой ловушки, теперь будут просто портить внутренний список ловушек. Нам пришлось написать специальный код, который определял такие случаи и заменял их на корректные вызовы.

Как были реализованы оконные ловушки в 16-битных Windows?

2011-09-06T02:55:00.000+04:00

Это перевод How were window hooks implemented in 16-bit Windows? Автор: Реймонд Чен.

Механизм отслеживания оконных ловушек был реализован существенно иначе в 16-битных Windows.

При этом использовались функции SetWindowsHook, UnhookWindowsHook и DefHookProc. Первые две функции существуют даже сегодня, но третья заменена простым макросом:

// 16-битный прототип
DWORD WINAPI DefHookProc(int nCode, WPARAM wParam,
                         LPARAM lParam, HHOOK FAR *phk);

// 32-битный макрос
#define DefHookProc(nCode, wParam, lParam, phhk)\
        CallNextHookEx(*phhk, nCode, wParam, lParam)

Предупреждение: весь код реконструируется по памяти. Его дух не тронут, но точные детали могут быть указаны не верно.

Чтобы установить ловушку в 16-битных Windows, вы сначала вызываете SetWindowsHook:

var
  g_hhkPrev: HHOOK;
...
  g_hhkPrev := SetWindowsHook(WH_WHATEVER, MyHookProc);

Возвращаемое значение от SetWindowsHook должно быть сохранено в глобальной переменной, которой мы дали несколько провокационное имя g_hhkPrev. Процедура ловушки выглядела вот так:

// В Win16 процедура ловушки возвращала DWORD, а не LRESULT
function MyHookProc(nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM): DWord;
begin
  if nCode >= 0 then
  begin
    ...
  end;
  Result := DefHookProc(nCode, wParam, lParam, g_hhkPrev);
end;

А когда вы заканчивали работу, то вы удаляли ловушку вызовом UnhookWindowsHook:

UnhookWindowsHook(WH_WHATEVER, MyhookProc);
g_hhkPrev := 0;

Внутренне, цепочка функций ловушек управлялась как связанный список, но вместо использования для хранения списка каких-то внутренних структур, связанный список управлялся через сами переменные HHOOK.

Внутренняя реализация SetWindowsHook была довольно простой:

// Этот массив инициализирован процедурами вида "ничего не делай"
var
  g_rgHook: array[0..NUMHOOKS - 1] of HOOKPROC;

function SetWindowsHook(nType: Integer; pfnHookProc: HOOKPROC): HHOOK; 
var
  hhkPrev: HHOOK;
begin
  hhkPrev := HHOOK(g_rgHook[nType]);
  g_rgHook[nType] := pfnHookProc;
  Result := hhkPrev;
end;

Установка ловушки просто записывала вашу процедуру ловушки в заголовок списка (цепочки ловушек), и возвращала предыдущее начало списка. Вызов ловушки заключался просто в вызове первой ловушки (головы списка):

function CallHook(nType, nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM): DWORD;
begin
  Result := g_rgHook[nType](nCode, wParam, lParam);
end;

Каждая процедура ловушки сначала выполняла свою работу, а затем передавала управление следующему элементу в цепочке, вызывая DefHookProc и передавая ему HHOOK:

function DefHookProc(nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM; var phk: HHOOK): DWord;
var
  pfnNext: HOOKPROC;
begin
  pfnNext := HOOKPROC(phk);
  if nCode >=0 then
  begin 
    Result := pfnNext(nCode, wParam, lParam);
    Exit;
  end;
  ... ещё код ...
end;

Как вы можете видеть, это чрезвычайно примитивно: вызов ловушки вызывает первую процедуру в списке, которая затем вызывает DefHookProc, которая знает, что HHOOK - это просто HOOKPROC, и она просто перенаправляет вызов вниз по списку, прямо вызывая эту самую функцию.

А волшебство здесь заключается в последнем шаге, когда вы снимаете ловушку. Вспомните, что правило вызова ловушек таково, что отрицательные коды должны передаваться в DefHookProc (или, по современному: CallNextHookEx) напрямую. Это соглашение позволяет подсистеме ловушек использовать отрицательные коды для ведения учёта. В данном случае мы использовали -1 как код "снять эту ловушку":

function UnhookWindowsHook(nType: Integer; pfnHookProc: HOOKPROC): BOOL;
begin
  Result := DefHookProc(-1, 0, LPARAM(pfnHookProc), HHOOK(g_rgHook[nType]));
end;

А затем начинается магия:

function DefHookProc(nCode: Integer; wParam: WinTypes.WPARAM; lParam: WinTypes.LPARAM; var phk: HHOOK): DWord;
var
  pfnNext: HOOKPROC;
begin
  pfnNext := HOOKPROC(phk);
  if nCode >=0 then
  begin 
    Result := pfnNext(nCode, wParam, lParam);
    Exit;
  end;
  case nCode of 
    -1: // пытаемся снять ловушку
    begin
      if pfnNext = HOOKPROC(lParam) then // нашли ловушку
      begin
        phk := HHOOK(pfnNext(-2, 0, 0));
        Result := Ord(True);
      end
      else
        // иначе - продолжаем искать
        Result := pfnNext(nCode, wParam, lParam);
    end;
    -2: // сообщить о следующей процедуре ловушке
      Result := DWORD(@phk);
  else
    Result := 0;
  end;
end;

Вот так - вся система оконных ловушек занимает всего несколько строк. Вам надо отдать должное Win16 за её компактный размер.

Прим.пер.: вырезан разбор примера работы.

Каждый раз, когда я говорю об этом, я восхищаюсь, как компактно была написана 16-битная Windows. Всего в двух десятках строк мы создали систему управления связанным списком функций, включающую в себя диспетчеризацию, а также поддержку удаления произвольного элемента из середины списка - и всё это без единого выделения памяти.

В следующий раз мы посмотрим на то, как люди злоупотребляли этой простой системой.

Кандидат на звание самого непонятного сочетания клавиш: Shift+F8

2011-09-05T02:54:00.000+04:00

Это перевод Candidate for most obscure keyboard shortcut: Shift+F8. Автор: Реймонд Чен.

Так получилось, что одной из самых непонятных сочетаний клавиш является Shift+F8, которая используется в listbox для несмежного расширенного выбора. Господи, сколько же слов.

Статья KB Q301583 не очень помогает в понимании, перечисляя это сочетание в разделе "Сочетания клавиш для диалоговых окон", даже хотя это не диалоговая комбинация клавиш. Это сочетание клавиш listbox-а.

Если в listbox включен режим расширенного выделения, то вы можете использовать комбинацию Shift+F8, чтобы создать несмежное расширенное выделение с клавиатуры (с помощью мыши вы можете сделать это просто делая Ctrl+щелчок). Нажмите Shift+F8 первый раз, чтобы войти в режим расширенного выделения, затем используйте стрелочки для перемещения по списку и нажмите Ctrl+Space или Shift+Space для выделения (или снятия выделения). Когда вы закончите - нажмите Shift+F8 ещё раз (или просто переместите фокус к следующему элементу управления).

И да, конкретно этот клавиатурный интерфейс просто кошмарен. Более естественный механизм использовал бы Ctrl+Стрелка для перемещения фокуса без изменения выбора, и Ctrl+Пробел для выбора (или отмены выбора) элемента. К счастью, элемент управления listview использовал именно этот подход вместо подражания сумасшедшему сочетанию клавиш Shift+F8.

Как менее наивный компилятор вызывает импортируемую функцию

2011-09-04T22:10:00.000+04:00

Это перевод How a less naive compiler calls an imported function. Автор: Реймонд Чен.

Если функция объявлена со спецификатором dllimport, то это указывает компилятору Visual Studio C/C++, что эта функция импортируется из другого (исполняемого) модуля, а не является обычной функцией в этом же исполняемом модуле. Имея на руках эту информацию, компилятор генерирует немного другой код, поскольку теперь он осведомлён об особенностях импортируемых функций.

Во-первых, теперь больше нет необходимости в функции-заглушке, потому что компилятор может сгенерировать инструкцию call [__imp__FunctionName]. Кроме того, компилятор знает, что этот адрес (адрес импортируемой функции) никогда не меняется, и, соответственно, он может оптимизировать многократное использование этого адреса, например:

    mov   ebx, [__imp__FunctionName]
    push  1
    call  ebx ; FunctionName(1)
    push  2
    call  ebx ; FunctionName(2)

(Примечание к сумасшедшим людям: подобная оптимизация означает, что у вас могут возникнуть проблемы, если вы исправляете таблицу импорта модуля после того, как код в модуле начал работу - потому что указатель на функцию может быть сохранён в регистр до того, как вы начали править импорт. Рассмотрите случай с примером выше, когда вы изменили запись в таблице __imp__FunctionName после выполнения инструкции mov ebx, [__imp__FunctionName]: ваша функция-перехватчик не будет вызвана, потому что старый указатель на функцию сохранён в регистре ebx).

Аналогично, если ваша программа попытается взять адрес импортируемой функции, которая была объявлена со спецификатором dllimport, то компилятор распознает эту операцию и преобразует её в загрузку адреса из таблицы адресов импортируемых функций.

В результате этого дополнительного знания, сообщаемого компилятору, функции-заглушки больше не нужны; компилятор знает, что ему надо идти прямо к таблице адресов импортированных функций.

Вызов импортируемой функции, наивный способ

2011-09-03T22:10:00.000+04:00

Это перевод Calling an imported function, the naive way. Автор: Реймонд Чен.

Библиотека импорта (import library) разрешает (resolve) символы импортируемых функций, но к ней не обращаются до этапа компоновки. Давайте посмотрим на наивную реализацию, когда компилятор слепо не осведомлён о существовании импортируемых функций.

В 16-битном мире это не вызывало никаких проблем. Компилятор генерировал дальний (far) вызов функции и оставлял внешнюю запись в объектном файле, указывающую, что вот этот адрес функции требует заполнения компоновщиком. На стадии компоновки линкер осознаёт, что этот внешний символ соответствует импортируемой функции, так что он собирает вместе все места её вызова в цепочку и создаёт запись импорта функции в таблице импорта модуля. В run-time эти записи исправляются загрузчиком ОС и все счастливы.

Давайте посмотрим, как справится с этой же ситуацией наивный 32-битный компилятор. Компилятор сгенерирует обычную инструкцию вызова функции, перекладывая разрешение адреса на компоновщик. Линкер увидит, что этот внешний символ, на самом деле, является импортируемой функций, и, ой, прямой вызов нужно переделать в косвенный. Но компоновщик не может переписать код, сгенерированный компилятором. Что же делать компоновщику?

Решение заключается во вставке ещё одно уровня косвенности (предупреждение: информация ниже не верна буквально, но она "достаточно правдоподобна". Мы копнём детали в следующих постах).

Для каждой экспортируемой функции создаётся два символа. Первый из них - запись в таблице импортируемых функций. Назовём его __imp__FunctionName. Конечно же, наивный компилятор не знает ни про какой префикс __imp__. Он просто генерирует код для инструкции call FunctionName, ожидая что компоновщик подставит нужный адрес.

Тут на сцену выходит второй символ. Он имеет имя FunctionName и является однострочной функцией, состоящей из одной-единственной инструкции: jmp [__imp__FunctionName] (генерируется компоновщиком). Эта крохотная заглушка предназначена для удовлетворения внешних ссылок на функцию FunctionName, и в свою очередь она генерирует ссылку на __imp__FunctionName, которая разрешается записью в таблице импортируемых функций.

Когда модуль загружается - его зависимости импорта будут разрешены, и реальный адрес функции будет записан в __imp__FunctionName. Затем, когда код вызовет импортируемую функцию, то сгенерированный компилятором код вызовет функцию FunctionName, которая является заглушкой, которая и вызовет целевую функцию через косвенный вызов.

Заметьте, что с наивным компилятором, если ваш код попытается взять адрес импортируемой функции, то он получит адрес заглушки, поскольку наивный компилятор оперирует с адресом функции FunctionName, не зная о том, что она импортируется из другого модуля и для неё, на самом деле, создаётся заглушка.

В следующий раз мы увидим, что с этой ситуацией сможет сделать менее наивный компилятор.

Смена дизайна импорта в 32-х битных Windows

2011-09-02T22:09:00.000+04:00

Это перевод Rethinking the way DLL exports are resolved for 32-bit Windows. Автор: Реймонд Чен.

За последние дни мы узнали, как работает экспорт и импорт функций в 16-битных Windows, а также что экспорт функций в Win32 очень похож на экспорт функций в 16-битных Windows. Но 16-битный импорт был полностью переписан в мире 32-битных Windows.

Вспомните, что в 16-битных Windows правки для импортируемой функции размещались по всему сегменту цепочкой. Это прекрасно работало в Win16, потому что там было глобальное адресное пространство: сегменты кода разделялись глобально, так что будучи единожды загруженным, сегмент мог быть использован любым процессом. Но 32-битные Windows использовали изолированные адресные пространства. Если правки были расположены по всему сегменту, то загрузка сегмента кода с диска (вернее - страницы сегмента кода) означала его модификацию, что не давало разделять один сегмент несколькими процессами (механизм copy-on-write). Даже если бы таблица правок хранилась бы во внешнем сегменте, вам всё равно пришлось бы править сегмент кода, чтобы указать цели для переходов (если вы достаточно умны, то вы могли бы разделять страницы между процессами, если все правки были бы одинаковы для всех этих процессов; но учёт изменений для этой модели был бы полным кошмаром).

Но помимо простой неэффективности, идея применения правок импорта к сегменту кода просто невозможна. К примеру, Alpha AXP имеет инструкцию "call direct" (прямой вызов), но она ограничена функциями, которые находятся лишь на расстоянии не более 128 Кб от места вызова. Если вы хотите вызвать функцию, которая находится дальше от вас, то вы должны загрузить адрес назначения во временный регистр и вызвать функцию через этот регистр. И, как мы видели ранее, загрузка 32-битного значения в регистр на Alpha AXP является двухступенчатой операцией, которая зависит от того, установлен или очищен 15-й бит того значения, которое вы хотите загрузить. Поскольку это импортируемая функция, то на этапе компиляции или компоновки вы понятия не имеете будет ли адрес целевой функции иметь 15-й бит или нет.

И Alpha AXP была далеко не единственной архитектурой, которая ограничивала расстояние для прямых вызовов. К примеру, Intel ia64 (Itanium) мог делать прямые вызовы функций только в пределах 4 Мб, а популярные сегодня архитектуры AMD x86-64 и Intel EM64T ограничивают вас 2 Гб. Да, это не звучит как ограничение пока вы не вспомните, что это - 64-разрядные процессоры с 16 эксабайтами адресного пространства. И снова мы видим, что архитектура x86 является странной (прим.пер.: в том смысле, что на ней нет ограничения на прямые вызовы в отличие от многих других архитектур).

Оба момента выше сделали правки импорта в сегменте кода нежелательными (и невозможными). Вместо этого правки импорта пришлось применять к данным. Вместо того, чтобы применять правку к каждому месту, где вызывается импортируемая функция, применяется всего одна правка в таблице указателей на функции. Это означает, что вызовы импортируемых функций на самом деле являются косвенными вызовами через указатель. К примеру, на x86 это означает, что вместо call ImportedFunction генерируется код, который говорит call [__imp__ImportedFunction], где __imp__ImportedFunction - это имя переменной (места в таблице), которая содержит указатель на эту импортируемую функцию.

Это означает, что правки импортируемых функций заключаются в простом поиске целевых адресов и их записи в таблицу импортируемых адресов (прим.пер.: хранимую в сегменте данных). Код не изменяется; он просто читает указатель на функцию в run-time и вызывает функцию через указатель.

С этой информацией мы теперь вооружены для более глубокого погружения в кое-какие последствия этого дизайна - что мы и сделаем в следующий раз.

Экспортируемые функции, являющиеся forwarder-ами

2011-09-01T22:09:00.000+04:00

Это перевод Exported functions that are really forwarders. Автор: Реймонд Чен.

В прошлый раз мы видели как экспортируемые функции в Win32 ведут себя похоже на экспорт функций в 16-битных Windows - только сместился акцент использования с импорта по номеру на импорт по имени. Этот акцент никак не выражен в формате исполняемого файла; и 16-битные и 32-битные DLL могут экспортировать функции по номеру и имени (и обоим одновременно).

Но в Win32 появляется новый тип экспортируемых функций, известный как forwarder.

Forwarder выглядит как обычная экспортируемая функция, за исключением того что запись в таблице экспорта по номерам говорит "Ох, на самом деле, я не функция в этой DLL. На самом деле - я функция вон в той DLL". К примеру, если вы сделаете

link /dump /exports kernel32.dll

То вы увидите что-то такое:

151   EnterCriticalSection (forwarded to NTDLL.RtlEnterCriticalSection)

Это означает, что если программа связана с KERNEL32.EnterCriticalSection, то загрузчик ОС молчаливо перенаправит функцию на NTDLL.RtlEnterCriticalSection. Forwarder-ы являются удобным способом сохранить внешний интерфейс, изменив функциональность выносом в отдельные DLL. Старая DLL продолжает экспортировать функцию, но сама функция была перемещена в новую DLL.

Трюк с forwarder - это лучше, чем иметь пустую функцию-заглушку в старой DLL, которая просто вызывает функцию в новой DLL: потому что функция заглушка создаёт зависимость между новой и старой DLL (в конце концов, старую DLL нужно связать с новой DLL, чтобы была возможность вызвать функцию!). А при использовании forwarder новая DLL не будет загружаться, если только кто-то не попросит перенаправленную функцию из старой DLL. В результате вы не платите за загрузку новой DLL пока кто-то её явно не попросит.

Okей, как мы увидели, с введением forwarder Win32 отошла от 16-битных Windows, но как только мы посмотрим на импорт, то увидим, что тут изменилось вообще всё. Мы посмотрим на эту историю в следующий раз.

Как экспортируются DLL функции в 32-битных Windows?

2011-08-31T22:08:00.000+04:00

Это перевод How are DLL functions exported in 32-bit Windows? Автор: Реймонд Чен.

Дизайнерам 32-битных Windows не нужно было беспокоиться о втискивании в 256 Кб памяти. Поскольку модули в Win32 построены на загрузке по запросу, то всё, что вам нужно сделать - спроецировать весь образ в память, а затем коснуться тех частей, которые вам нужны. Поэтому нет никакого различия между резидентной и не резидентной таблицами, так что имена экспортируемых функций просто записываются в исполняемый образ вместе с указателем (вернее относительным виртуальным адресом) на имя, хранимое в таблице экспорта.

В отличие от главной 16-битной таблицы экспорта, 32-битная таблица не является разрежённой. Иными словами, если ваша DLL экспортирует две функции с номерами 10 и 1000 - у вас будет таблица экспорта на 991 записей, состоящая из двух функций и кучи нулей. Поэтому вам не следует назначать номера функциям с большими пробелами в нумерации - иначе вы будете зря тратить пространство в таблице экспорта.

Как я заметил выше, теперь есть только одна таблица экспортируемых имён, поскольку вам не нужно делать отличия между резидентными и не резидентными именами. Таблица экспортируемых имён работает в той же манере, что и в 16-битных Windows, проецируя имена на номера. В отличие от 16-битных таблиц, где порядок не имеет значения, таблица экспортируемых имён в 32-битных Windows должна быть отсортирована, чтобы система могла воспользоваться (эффективным) двоичным поиском для ускорения поиска имён.

Как и в 16-битных Windows, каждому имени присваивается номер. Если программист не указывает номер, то его назначает компоновщик, и, как и в 16-битных Windows, автоматически присваиваемые значения могут отличаться в сборках. Однако тут есть существенное отличие в моделях использования: вспомните, что в 16-битных Windows импорт по имени не поощрялся (по соображениям производительности), и в результате обычно каждой экспортируемой функции явно присваивался номер, что и было предпочтительным способом связывания функций. С другой стороны, именованный импорт в Win32 является нормой, а явное присваивание номеров функций ушло в прошлое. Это означает, что номера в таблице экспорта не фиксированы. К примеру, посмотрите на номера, присваиваемые функции LocalAlloc из kernel32 за эти годы:

Windows NT 3.1	314
Windows NT 3.5	372
Windows 95	501
Windows NT 4.0	407

Но некоторые люди имеют привычку "взламывать" (reverse-engineer) библиотеки импорта - вероятно потому, что им лень качать Platform SDK чтобы получить официальные библиотеки импорта. Проблема с генерацией библиотеки импорта заключается в том, что вы не можете сказать, был ли номер, скажем, функции LoadLibrary присвоен явно программистом (и, значит, будет постоянен) или же был назначен автоматически компоновщиком (и в этом случае он будет меняться). Утилиты генерации библиотек импорта могут просто перестраховаться и всегда использовать именованный импорт, но по какой-то причине они часто предпочитают импорт по номерам (вероятно, это остаток из времён 16-битных Windows, где такой способ импорта был предпочитаемым).

Этот неудачный выбор части утилит по генерации библиотек импорта жить опасной жизнью создал проблемы совместимости команде DirectX (я не знаю, почему именно DirectX оказался под ударом больше остальных. Возможно, потому что у разработчиков игр нет времени учить детали Win32; они просто хотят писать их игры). Как только кто-то использовал такую утилиту, он оказался привязанным к функциям DirectX вроде DirectDrawCreate по номеру, а не по имени. А когда вышла следующая версия DirectX и этому имени был присвоен другой номер компоновщиком, их программы стали вылетать. Команде DirectX пришлось поднять из архива старые DLL, тщательно выписать все номера функций (присвоенные случайным образом компоновщиком) и в точности повторить это присвоение вручную, так чтобы эти номера более не менялись бы в будущем.

Есть и другие причины, почему вы не можете сгенерировать библиотеку импорта по DLL; я подниму эти причины в следующий раз, когда буду обсуждать импорт из DLL.

В следующий раз - переходники.

Как импортировались DLL функции в 16-битных Windows?

2011-08-30T22:08:00.000+04:00

Это перевод How were DLL functions imported in 16-bit Windows? Автор: Реймонд Чен.

В прошлый раз я рассказал о том, как экспортировались функции в 16-битных Windows. Сегодня мы посмотрим на их импорт.

Каждый раз, когда сегмент загружается с диска в память, сначала читается raw-содержимое сегмента с диска, а затем применяются relocation-правки. Правка для импортируемой функции состоит из имени целевой DLL, целевой функции (либо её имени, либо номера), и позиции первого места в сегменте, где нужно произвести правку. Все импортируемые адреса являются far-адресами, поскольку они ссылаются на другой сегмент (почему? если бы они были в том же сегменте, то это означало бы, что они расположены в той же DLL, так что это получился бы импорт функции из самого себя!). На 16-битных Windows дальний указатель занимает 4 байта (двухбайтовый селектор и двухбайтовое смещение), а поскольку точный адрес функции не известен в момент компиляции DLL, то эти 4 байта являются просто заглушками - они помещаются в файл с тем, чтобы быть заполненными настоящими значениями в run-time, когда будет получен адрес импортируемой функции. И эти байты заглушек служат двойной цели.

Все вызовы сегмента одной и той же импортируемой функции связываются в список; запись в relocation таблице ссылается только на первый элемент этого списка. А что насчёт остальных вызовов? На них указывают заглушки! К примеру, предположим, что у нас есть сегмент, который требует две правки для функции GetPrivateProfileInt, которая является функцией ядра с номером 127. Тогда в relocation таблице будет создана одна запись, которая говорит: "этот сегмент требует функцию номер 127 из KERNEL; начало по смещению 01D1". Копия сегмента на диске может выглядеть так:

...
`01D0`	`9A`
`01D1`	`FE`
`01D2`	`01`
`01D3`	`00`
`01D0`	`00`
...
`01FD`	`9A`
`01FE`	`FF`
`01FF`	`FF`
`0200`	`00`
`0201`	`00`
...

Чтобы применить правку, мы вызываем GetProcAddress для получения настоящего адреса функции 127. Затем мы идём к месту первой правки (это место со смещением $01D1), записываем в него адрес, а затем смотрим на значение, которое мы только что перезаписали (конечно, мы должны его сохранить перед записью). Это значение равно $01FE, поэтому мы идём к месту по смещению $01FE и снова записываем адрес. Перезаписанное значение равно $FFFF, что означает конец цепочки правок.

Но что если вызов GetProcAddress будет неудачным? (к примеру - в KERNEL нет никакой функции 127). Тогда вместо записи адреса целевой функции, загрузчик запишет адрес специальной функции-заглушки, которая вызывает фатальную ошибку "Call to Undefined Dynalink".

Okей, это было краткое введение в импорт и экспорт функций в 16-битных Windows. В следующий раз мы посмотрим на переход на 32-битные Windows и решения дизайна, которые сформировали новую модель экспорта-импорта.

Как экспортировались DLL функции в 16-битных Windows?

2011-08-29T22:07:00.000+04:00

Это перевод How were DLL functions exported in 16-bit Windows? Автор: Реймонд Чен.

Весь смысл динамических библиотек (DLL) заключается в динамическом связывании. В то время как статические библиотеки встраиваются в конечный продукт, модуль, который использует динамическую библиотеку, просто говорит: "мне, пожалуйста, функцию X из модуля Y, спасибо". Эта техника имеет преимущества и недостатки. Одно из преимуществ - эффективное использование места на диске и в памяти, поскольку существует только одна копия модуля, вместо отдельных копий для каждого модуля. Второе преимущество - обновление DLL может быть выполнено без перекомпиляции всех программ, её использующих. С другой стороны, возможность менять функциональность также является и одним из недостатков DLL, поскольку одна программа может изменить DLL и вызвать этим каскадные эффекты в других клиентах DLL.

В любом случае, давайте начнём с того, как 16-битные Windows управляли импортом и экспортом. После этого мы посмотрим что было изменено при миграции на 32-битные Windows, а затем мы посмотрим на импорт с точки зрения компилятора.

16-битная DLL имела не одну, а целых три таблицы экспорта (на самом деле всё было немного сложнее, чем я описываю здесь, но я собираюсь опустить некоторые занудные детали, чтобы ваши головы не взорвались от переизбытка информации). Самая важная таблица представляла собой разрежённый массив функций, проиндексированных с 1("ordinal"). Это и есть таблица функций, которая является мастер-списком всех экспортируемых функций. Если вы запрашивали функцию по номеру (ordinal), этот номер искался именно в этой таблице. Физически таблица устроена не так просто - из-за разрежённости, но логически она выглядит так:

Номер	Адрес	прочее
1	02:0014	...
2	04:0000	...
5	02:02C8	...

Первая колонка в таблице представляет собой номер функции, а вторая описывает размещение функции (заметьте, что в этой DLL нет функций 3 и 4).

Интересные вещи начинаются, когда вы хотите получить функцию по её имени. Таблица экспортируемых имён представляет собой список имён функций с ассоциированными номерами. К примеру, секция экспортируемых имён для 16-битного оконного менеджера выглядела так:

...
`ClipCursor`	16
`GetCursorPos`	17
`SetCapture`	18
...

Если кто-то просил адрес функции "ClipCursor", то сначала проверялась таблица экспортируемых имён и из неё извлекался номер 16, после чего этот номер использовался для обращения к мастер-таблице, упомянутой выше. Хотя вы не видите этого здесь, но не существовало никакого требования, чтобы имена в таблице экспортируемых имён шли в каком-то определённом порядке или чтобы каждая функция с номером имела бы экспортируемое имя.

Подождите-ка, я сказал "таблица экспортируемых имён"? Ох, извините, это было сильное упрощение. На самом деле было две таблицы экспортируемых имён: резидентная таблица имён и не резидентная таблица имён. Как следует из их названий, имена в резидентной таблице оставались в памяти всё время, пока DLL была загружена, а имена из не резидентной таблицы загружались в память только когда кто-то вызывал GetProcAddress (или её эквивалент). Это различие появилось из-за очень жёстких ограничений на память, с которыми Windows приходилось работать в те дни. К примеру, оконный менеджер имел около шестисот экспортируемых функций; если бы все эти функции были резидентными, то они занимали бы более 10 Кб памяти. Это означает, что вы тратите 4 процента вашей памяти (машины с 256 Кб), чтобы хранить вещи, которые вам не нужны 99% процентов времени.

Большой размер таблицы экспортируемых имён означал, что только функции, часто передаваемые в GetProcAddress, заслуживают появления в резидентной таблице. Для большинства DLL таких функций не было вообще, так что таблица резидентных имён была обычно пустой (для пущей безопасности удалены голово-взрывные детали).

Поскольку получение функции по имени было таким дорогим (загрузка не резидентной таблицы с диска), то все функции ОС экспортировались по именам и номеру. Импорт функции по номеру был предпочтителен - это позволяло полностью избегать таблицы имён.

Заметьте, что каждая функция с именем имела соответствующий номер. Если вы не присваивали номер функции явно, то это делал за вас компоновщик (линкер), однако автоматически сгенерированное значение не обязано было сохраняться одинаковым при каждой сборке. Обычно эта ситуация не возникала на практике, потому что все старались явно присваивать номера функциям по причинам, указанным выше - чтобы избежать огромных накладных расходов импорта функции по имени.

Это был краткий обзор экспорта функций в 16-битных Windows. В следующий раз мы посмотрим на то, как они импортировались.

Pidl и моникеры делают примерно одно и то же, только по-разному

2011-08-28T22:07:00.000+04:00

Это перевод Pidls and monikers do roughly the same thing, just backwards. Автор: Реймонд Чен.

Работая с Оболочкой (Shell) Windows, вам наверняка в какой-то момент пришлось работать с указателем на список ID элементов (pointer to item ID list), известным как "pidl" (рифмуется с "middle"). С другой стороны, работая с OLE, вы могли работать с моникерами (moniker). В каком-то смысле они делают одно и то же. Они позволяют вам ссылаться на какой-то объект внутри пространства имён (с которым вы как-то работаете), они имеют иерархическую структуру, вы можете их сериализовать и т.п.

Но почему тогда команда Оболочки Windows изобрела pidl-ы, если моникеры делали ровно это же?

Фундаментальное отличие между pidl и моникерами - не в том, что они делают, а скорее в их "акценте". Моникер - это COM объект. Это означает, что они существуют в форме COM интерфейса (IMoniker), что означает, что код, стоящий за объектом, должен быть загружен и готов к работе. Вы можете сконвертировать моникер в данные, но это не то, как обычно проводят свою жизнь моникеры. Если у вас есть массив моникеров, то весь код под капотом должен быть проинициализирован.

Pidl, с другой стороны, проводит большую часть своей жизни будучи засериализован в данные. COM объект появляется только когда вы производите связывание (bind). Рассмотрите, к примеру, случай, когда вы перечисляете содержимое папки. Эта операция генерирует pidl для каждого элемента в папке, но создание и хранение этих pidl не требует выполнения кода каждого элемента. Папка с тысячей элементов создаст тысячу кусков данных, а не тысячу COM объектов. Рассмотрим, к примеру, папку с тысячей таблиц Excel. Если вы открываете эту папку, то вам бы не хотелось запускать Excel для каждой из тысячи таблиц в папке (для обслуживания элементов). На этом этапе вы пока просто говорите про файлы. И лишь когда пользователь щёлкает на файле, вы хотели бы запускать Excel.

Поскольку Оболочка большую часть времени проводит в "разговоре о вещах", а не "разговорах с вещами", то объект, который большую часть времени "мёртв", является более предпочтительным. Вы можете сказать, что разница между pidl и моникерами является вопросом жизни и смерти (прим.пер.: это юмор, если кто не понял).

Не всякий человек с не-Windows разделом является гиком

2011-08-27T22:06:00.000+04:00

Это перевод Not everybody with a non-Windows partition type is a geek. Автор: Реймонд Чен.

В обсуждении поста "Почему установщик Windows записывает новый загрузочный сектор?" (прим.пер. имеется в виду оригинал) некоторые комментаторы предложили такое поведение: если на машине обнаруживается не-Windows раздел, то предполагать, что машина принадлежит техно-гику. Таким образом, типичный пользователь компьютера может быть спасён от лицезрения технического диалога с гик-вопросом, на которой они не смогут ответить.

Проблема в этом плане в том, что не всякий человек с не-Windows разделом на жёстком диске обязательно является техно-гиком. Многие OEM-машины (особенно ноутбуки - прим.пер.) поставляются с диском, разбитым на два раздела. На первом стоит Windows, а второй - не-Windows раздел, который имеет небольшой размер и содержит утилиты диагностики и восстановления системы (иногда - дистрибутивный образ мастер-копии системы). Наличие этого небольшого раздела не слишком известно, поскольку он работает только в редких случаях загрузки с "system recovery CD" от поставщика машины.

Следствие из этого состоит в том, что если бы установщик Windows принял бы этот подход "человек с не-Windows разделом должен быть гиком", то в итоге мы бы пометили гиками ужасно много людей (многие из которых гиками не являются).

Вы также можете сказать: "ну, только гики устанавливают операционные системы. Обычные люди покупают компьютер с предустановленной системой. Тот факт, что они вообще запустили установщик Windows, доказывает, что они - гики. Поэтому, установщик Windows должен быть оптимизирован для использования гиками". Действительно, предпосылки этого аргумента (что только гики устанавливают Windows) верны - но только если вы достигли устойчивого состояния. В течение нескольких месяцев сразу после выпуска новой версии Windows, Windows устанавливают все подряд - как гики, так и простые люди (кроме того, наплыв установок Windows приходится на каждое Рождество). Рецензенты журналов, пишущие обзоры новой операционной системы, будут устанавливать Windows для пробы. Так что впечатление от установки - это первое, что они увидят. Так что установке лучше бы быть гладкой и безболезненной.

Прежде чем учиться опознавать неправильное, вам нужно узнать, что есть правильное

2011-08-26T22:06:00.000+04:00

Это перевод Before you can learn to recognize what's wrong, you must learn to recognize what's right. Автор: Реймонд Чен.

Иногда, когда я отлаживаю проблему, я могу проигнорировать какой-то поток, а кто-то спросит: "а что делает этот поток? Почему ты его игнорируешь?"

Мой ответ: "Я понятия не имею, что он делает, но что бы он ни делал, это - нормально".

Tess публикует отличную серию постов, посвящённых отладке CLR, но один из самых важных уроков - это где вы учитесь игнорировать вещи, когда отлаживаете зависание в ASP.NET.

Зависания и блокировки могут быть сложны в отладке, потому что у вас нет исключения, которое кричит: "эй, смотри на меня, вот она проблема, я - это баг!". Вместо этого программа просто замирает и вам нужно понять почему. При этом вам нужно искать что-то неординарное, необычное, но чтобы вы могли опознать это что-то - вам нужно знать, как обычно выглядят вещи в вашем процессе.

Ну так сделайте это. Запустите программу, пусть она работает, а вы остановите её в отладчике и просто посмотрите на неё. Отметьте то, что вы увидите. Это - вещи, которые происходят в вашей программе, когда всё идёт своим чередом. Так выглядит ваша программа, когда она работает в нормальном режиме. Теперь, когда вы знаете как выглядят нормальные вещи в вашей программе, вы можете опознать не нормальные.

Заметьте, что вам даже не нужно понимать, что все эти нормальные вещи значат или делают. К примеру, когда я подключаю отладчик к процессу, я часто вижу потоки, ожидающие RPC или спящие в пуле потоков ядра. Я понятия не имею, что они делают, но раз уж они тут и раньше были, то я их игнорирую.

Нет, а почему именно 160x31?

2011-08-25T22:05:00.000+04:00

Это перевод No, really, why is it 160x31? Автор: Реймонд Чен.

Когда я ранее пояснял, почему свёрнутые (минимизированные) окна имеют размер 160x31, я не пояснил, почему размером выбрано именно ровно 160 и 31.

Ширина минимизированного окна определяется полем iWidth в записи TMinimizedMetrics. Вы можете получить и изменить эту запись с помощью функции SystemParametersInfo (вас будут интересовать флаги SPI_GETMINIMIZEDMETRICS и SPI_SETMINIMIZEDMETRICS). Некоторые люди упоминают использование значение MinWidth в реестре, но они не правы. К примеру, заметьте, что исправление MinWidth требует выхода из системы, а использование SPI_SETMINIMIZEDMETRICS действует немедленно. Это потому что SPI_SETMINIMIZEDMETRICS обновляет внутреннее состояние системы, а правки реестра просто меняют значение в БД, на которую никто не смотрит (после запуска).

Что насчёт высоты? А это просто высота строки-заголовка (caption bar), которую вы можете изменить на вкладке "Оформление" апплета "Экран" панели управления (программно вы можете использовать эту же полезную функцию SystemParametersInfo, но в этот раз используя поле iCaptionHeight записи TNonClientMetrics).

Максимальный размер переменных окружения - это 32 или 64 Кб?

2011-08-24T22:04:00.000+04:00

Это перевод Is the maximum size of the environment 32K or 64K? Автор: Реймонд Чен.

Кажется, есть некоторая путаница в максимальном размере переменных окружения: 32 Кб или 64 Кб. Какое значение правильное?

Оба.

Ограничение - 32'767 Unicode символов, что есть 65'534 байт. Назовите это 32 Кб или 64 Кб - как вам угодно. Но только убедитесь, что вы включили единицу измерения в ваши утверждения, если она не следует из контекста.

Безопасность: не забывайте обнулять вещи, на которые вам наплевать

2011-08-23T22:04:00.000+04:00

Это перевод Security: Don't forget to initialize the stuff you don't care about. Автор: Реймонд Чен.

Затерянным в волнении уязвимостей повышения привилегий является простое раскрытие информации через отсутствующую инициализацию мусора (прим.пер.: понятия не имею, зачем оригинальное предложение так построено).

Сегодня каждый знаком с использованием функции SecureZeroMemory для гарантии того, что буфера, содержащие чувствительную (важную) информацию, очищены после работы с ними (*), но вы также должны очищать буфера перед их записью в другое место. Рассмотрим, к примеру, такой формат данных:

type
  TFileHeader = packed record
    dwMagic: DWORD;
    dwVersion: DWORD;
    wszComment: array[0..256-1] of WideChar;
    cbData: DWORD;
    // далее следует cbData байт данных
  end;

Код, который заполняет такие файлы, мог бы выглядеть так:

function SaveToFile(hFile: THandle; pszComment: PWideChar; cbData: DWORD; pbData: PByte): Boolean;
var
  cbWritten: DWORD;
  fh: TFileHeader;
begin
  fh.dwMagic := FILE_MAGICNUMBER;
  fh.dwVersion := FILE_CURRENTVERSION;
  fh.cbData := cbData;
  Result := SUCCEEDED(StringCchCopyW(fh.wszComment, 256, pszComment)) and
                  WriteFile(hFile, @fh, SizeOf(fh), cbWritten, nil) and
                  (cbWritten = SizeOf(fh)) and
                  WriteFile(hFile, pbData, cbData, cbWritten, nil) and
                  (cbWritten = cbData);
end;

Увидели баг безопасности?

Если комментарий к файлу будет менее 255 символов, то байты после терминирующего нуля будут содержать не инициализированный мусор со стека. Мусор со стека может содержать интересную информацию, которую вы бы не хотели выкладывать в файл. Конечно, он не будет содержать информацию, которую вы уже идентифицировали как чувствительную (вроде паролей) - потому что вы уже подчистили её; но мусор может содержать информацию, хотя и менее критическую, но всё же привлекательную для злоумышленника. К примеру, у вас может утечь имя аккаунта.

Мне рассказали, что одна сетевая программа известной компании содержала аналогичный баг. Они использовали очень продвинутый алгоритм "смены пароля", детали которого сейчас не важны. Дизайном было предусмотрено, что по сети передавались только сложно зашифрованные данные. Таким образом, если кто-то просматривал сетевые пакеты, то он не мог увидеть ничего интересного. Вот только у них был баг в их клиентской программе: когда они отправляли зашифрованный пароль на сервер, они забыли обнулить не используемые байты в пакете "смена пароля". А в этих данных была... ага, верно: не зашифрованная копия пароля.

Примечание переводчика:
(*) SecureZeroMemory практически не известна в Delphi, потому что предназначена для обхода оптимизатора C++ (видимо, по причине того, что ZeroMemory в C++ является макросом, а не функцией; поэтому её "вызов" последним действием на переменную может быть выброшен оптимизатором). Вместо неё в Delphi используется стандартная системная ZeroMemory (которая в Delphi является обычной функцией; фактически - inline-переходником к FillChar) или чисто Delphi-ёвая FillChar.

Событие с авто-сбросом - это просто глупый семафор

2011-08-22T22:03:00.000+04:00

Это перевод An auto-reset event is just a stupid semaphore. Автор: Реймонд Чен.

Когда вы создаёте событие с помощью функции CreateEvent, вы указываете, хотите ли вы создать событие с авто-сбросом (auto-reset event) или с ручным сбросом (manual-reset event).

Событие с ручным сбросом прозрачно для понимания: если событие сброшено, то вы ждёте сигнального состояния; если событие установлено (в сигнальном состоянии), то ожидания не происходит (ожидание удовлетворяется сразу). Не играет значения, сколько человек ждут события; они все обрабатываются одинаково, а состояние события не зависит от числа его ожидающих.

Событие с авто-сбросом - более запутывающая штука.

Вероятно, проще всего думать о событии с авто-сбросом как о семафоре с максимумом счётчика равным единице. Если событие сброшено, то вы ждёте сигнального состояния. Если событие устанавливается, то один из ожидающих будет отпущен, а остальные продолжат ждать (и из нашего обсуждения PulseEvent вы уже знаете, что то, кто именно будет освобождён, - не определено).

"Ага!" в случае событий с авто-сбросом заключается в случае, когда вы устанавливаете уже установленное событие. Поскольку у события есть только два состояния (сброшенное и сигнальное), то установка события, которое и так находится в сигнальном состоянии, не даст никакого эффекта, ничего не изменит. Если вы используете событие, чтобы контролировать ресурс в модели producer/consumer, то "установка уже установленного события" приведёт к потере токена. Рассмотрим такой шаблон:

Producer	Consumer
	Ожидание
Задать работу
`SetEvent`
	Проснуться и сбросить событие
	Работа
Задать работу
	Wait
`SetEvent`
	Проснуться и сбросить событие
	Работа
...	...

Но что если тайминг немного не совпадёт? Что если потребитель (consumer) будет медленно делать работу (либо же producer будет слишком быстро её генерировать)?

Producer	Consumer
	Ожидание
Задать работу
`SetEvent`
	Проснуться и сбросить событие
Задать работу
`SetEvent`
	Работа
Задать работу
`SetEvent` (без эффекта)
	Ожидание удовлетворено сразу
	Сброс события
	Работа
	Ожидание

Заметьте, что producer создал три задания на работу, но consumer обработал только два. Третий SetEvent просто ничего не сделал, поскольку событие было уже установлено (вы увидите ту же проблему, если попытаетесь увеличить счётчик семафора за его максимум). Если вы хотите, чтобы оба числа соответствовали друг другу, то вам нужно использовать семафор с максимальным значением счётчика выше чем максимум элементов в очереди (прим.пер.: либо же consumer при выходе из ожидания может обрабатывать не один элемент, а все в очереди).

Мораль истории: знайте ваши инструменты, знайте их ограничения и используйте правильный инструмент для правильной задачи.

Одноэкземплярная программа является своим собственным отказом в обслуживании

2011-08-21T22:02:00.000+04:00

Это перевод A single-instance program is its own denial of service. Автор: Реймонд Чен.

Есть много способов, которыми программа может достичь поведения запуска в едином экземпляре; я не буду разбирать их. Но как только люди встают на путь программы с одним запущенным экземпляром, они тут же спотыкаются о другую проблему при анализе безопасности: отказ в обслуживании (denial of service attack).

Мы используем мьютекс с фиксированным именем, чтобы определить, не запущена ли уже копия программы. Но это также означает, что злоумышленник может создать мьютекс с таким именем до запуска программы, блокируя, таким образом, запуск нашей программы! Как я могу предотвратить этот тип отказа в обслуживании?

Если атакующий запущен в том же контексте безопасности, что и ваша программа (ну, или будет запущена ваша программа), то вы ничего не можете сделать с этой ситуацией. Какое бы "секретное рукопожатие" вы ни придумали бы для определения запуска второго экземпляра - атакующий всегда может просто повторить его. Поскольку он запущен в том же контексте безопасности - он может ровно столько же, сколько и ваша программа.

Но посмотрите на этот вопрос шире: одноэкземплярная программа является "своим собственным отказом в обслуживании"! В конце концов, первый экземпляр программы блокирует последующие запуски программы. Ваши требования к программе изначально являются уязвимостью в безопасности. Соответственно, вы не можете защитить себя от отказа в обслуживании, потому что вы хотите иметь отказ в обслуживании.

Но что вы можете сделать - понять и сузить область уязвимости. Очевидно, вы не можете защитить себя от атакующего, работающего на том же уровне привилегий, что и вы. Но вы можете защитить себя от атакующих, работающих под другими (не привилегированными) учётными записями. Для этого вам нужно включить защищаемые объекты в процесс вашего программного "рукопожатия". Тогда простые пользователи (не администраторы) не смогут заблокировать запуск вашей программы для других пользователей. Худшей вещью, которой допускается делать не администратору - делать свою жизнь жалкой, но не жизнь других пользователей.

Почему нет программного способа изменить порядок элементов в меню Пуск?

2011-08-20T22:01:00.000+04:00

Это перевод Why can't you programmatically reorder the items on the Start menu? Автор: Реймонд Чен.

Классическое меню Пуск и часть "Все программы" меню Пуск в стиле Windows XP позволяют вам изменить порядок ярлыков, показываемых в них. Вы можете использовать перетаскивание для его упорядочивания, либо же просто использовать сортировку по имени. Но почему нет никакого программного интерфейса для выполнения этих операций?

Потому что эта сила может использоваться во зло чаще, чем во имя добра.

Как я отмечал ранее, меню Пуск является крайне ценным местом. Если бы к порядку элементов меню Пуск был дан программный интерфейс, то программы бы просто использовали его для своего пиара, помещая себя на вершину (и, вероятно, понижая своих конкурентов). Как только вы осознаете, что программы собираются делать с меню Пуск, вы поймёте, что пользователь сам потеряет способность упорядочивать элементы меню - потому что программы просто будут замещать выбор пользователя своими установками.

Разбираемся, что на самом деле значит "значимые цифры"

2011-08-19T22:01:00.000+04:00

Это перевод Understanding what significant digits really mean. Автор: Реймонд Чен.

Числа с плавающей запятой двойной точности (double-precision floating point number) содержат 15 значащих цифр. Что это значит на самом деле?

Я умножил 0,619207 на 10'000'000 и получил 6'192'069,999999991 вместо 6'192'070. Это же только шесть цифр; где мои обещанные пятнадцать?

Разговор о значащих цифрах - это просто сокращение для относительной погрешности. Это не означает, что первые пятнадцать цифр в точности совпадают с результатом (если вы проведёте больше времени в численном анализе, то услышите как люди говорят о вещах вроде "пять с половиной значащих цифр". Если бы значением "значащих цифр" было таким буквальным, то как вы могли бы иметь половину цифры?).

Относительная ошибка в данном вычислении равна 9 / 6'192'070'000'000'000 = 1,5 × 10^-15, что согласуется с точностью в пятнадцать значащих цифр.

Но даже если вы примете буквальное значение слов, то числа примера всё ещё равны друг другу до пятнадцати знаков. Вспомните, что 0,99999... = 1, и поэтому значения

6192069,999999991
6192069,999999999...

согласуются на пятнадцать значащих цифр - как и было обещано.

А если вы адепт гипер-буквального чтения и отказываетесь принимать трактовку 0,99999... = 1, то вам придётся признать, что единственными возможными значениями для числа значащих цифр являются ноль и бесконечность!

Рассмотрите пример вычислений, в результате которых получается ровно 1, а сами вычисления выполняются с точностью N значащих цифр (где N > 0). Поскольку вы не принимаете, что 0,9 согласуется с 1,0 в одной значащей цифре, то единственными значениями, которые согласуются с 1,0 хотя бы по одной значащей цифре, будут числа в форме "один, запятая, что-то". Обозначим результат вычислений через 1 + ε, где 0 ≤ ε < 1. Теперь вычтем это из 2.0, что даст 1 − ε. Этот результат тоже должен иметь N значащих цифр. И снова, поскольку вы не принимаете, что 0,9 согласуется с 1,0 по одной значащей цифре, то чтобы этот результат был бы хорош для N значащих цифр (N > 0), результат должен иметь форму "один, запятая, что-то". Обозначим результат как 1 + δ, где 0 ≤ δ < 1.

Итак, мы получили 1 − ε = 1 + δ, откуда следует ε = −δ. Поскольку и δ, и ε больше или равны нуля, то единственное решение этого уравнения: ε = δ = 0. Соответственно, единственным числом, которое равно единице до какого-то ненулевого числа значащих цифр (если вы подписались на гипер-буквальную трактовку) будет сама единица. Другими словами, единственное возможное (не нулевое) число значащих цифр - бесконечность. И я думаю, что мы все согласны в том, что если единственными значениями количества значащих цифр были бы ноль с бесконечностью, то вся концепция значимых цифр была бы глупой и бесполезной.

Вот почему значимые цифры не используют гипер-буквальное определение.

Свойства оконных классов применяются ко всем окнам этого класса

2011-08-18T22:00:00.000+04:00

Это перевод Window class properties apply to all windows that belong to the class. Автор: Реймонд Чен.

Свойства оконных классов применяются ко всем окнам этого класса. Именно поэтому они и называются классовыми свойствами. Это выглядит как очевидная вещь, когда её облекают в слова, но я видел множество "решений", которые теряют из вида этот простой факт.

Все свойства, устанавливаемые в записях TWndClass (или TWndClassEx) являются свойствами оконного класса, равно как и свойства, доступ к которым происходит через Get/SetClassWord/Long/LongPtr. Это означает, что когда вы меняете эти свойства, то это изменение затрагивает весь оконный класс. К примеру, если вы пишете:

SetClassLongPtr(hwnd, GCLP_HCURSOR, LONG_PTR(hcurNew));

то вы не просто меняете курсор окна hwnd. Вы меняете курсор всех окон того же оконного класса, что и оконный класс hwnd. К примеру, если hwnd является описателем элементом управления edit, то этим вы измените курсор во всех edit-ах!

Но что если вам нужно изменить классовое свойство только для одного окна, вместо всех окон?

Если вы хотите изменить меню, фон, курсор или значок конкретного окна, то вы можете заместить умолчания класса на уровне окна:

Свойство	Метод
Меню	`SetMenu(hwnd, hmenuNew)` + удалить старое меню
Фон	Заместить `WM_ERASEBKGND`
Курсор	Заместить `WM_SETCURSOR`
Иконка	`SendMessage(hwnd, WM_SETICON, iconSize, LPARAM(hiconNew));`

Прим.пер.: вероятно, людей смущает тот факт, что функции Get/SetClassXYZ принимают аргументом окно, а не оконный класс.