none
Shell_NotifyIcon в 64х разрядных приложениях

    Вопрос

  • Пытаюсь заставить работать Shell_NotifyIcon в 64х разрядном приложении. https://msdn.microsoft.com/en-us/library/windows/desktop/bb762159(v=vs.85).aspx В 32х разрядном проблем не возникает, а вот при переходе на 64х ступор. Я понимаю что вся проблема заключается в структуре данных, вернее в размере этой структуры:

    typedef struct _NOTIFYICONDATA {
      DWORD cbSize; // 4 байта
      HWND  hWnd;  // 8 байт
      UINT  uID; // 4 байта
      UINT  uFlags; // 4 байта
      UINT  uCallbackMessage; // 4 байта
      HICON hIcon; // 8 байт
      TCHAR szTip[128]; // 128*2 байта 
      DWORD dwState; // 4 байта
      DWORD dwStateMask; // 4 байта
      TCHAR szInfo[256]; // 256*2 байта
      union {  // 4 байта
        UINT uTimeout;
        UINT uVersion;
      };
      TCHAR szInfoTitle[64]; // 64*2 байта
      DWORD dwInfoFlags; // 4 байта
      GUID  guidItem; // 16 байт
      HICON hBalloonIcon; // 8 байт
    } NOTIFYICONDATA, *PNOTIFYICONDATA;
    

    Весь размер струкруры составляет 968 байт, что кратно, как и положено, 8 байтам. Но функция упорно не желает работать. Подскажите в чем особенность использования данной функции в 64х разрядной среде? Полагаю что проблема все же в размерах типов, вот только не знаю куда копать... (((

    13 ноября 2017 г. 19:24

Все ответы

  • Насколько я знаю, нет никакой особенности использования Shell_NotifyIcon в 64-битных приложениях (как и 99% Windows API - он был спроектирован так, чтобы не заботится о платформе). Ищите проблему в другом месте.

    Так как 64-битные приложения отличаются от 32-битных размером указателя, проблему может вызывать код, манипулирующий внутренней структурой указателей и некоторые API-функции, зависящие от этого (например, GetClassLong/GetWindowLong при получении дескрипторов).

    14 ноября 2017 г. 5:48
  • Я тоже так считал. Но видимо вопрос лежит немного в другой плоскости. К примеру после первого поля приходится вставлять дополнительные 4 байта, чтобы указатель, находящийся во втором поле, уместился в заданной области. А вот как сами разработчики решают вопрос без расширителей, я пока так и не понял.
    14 ноября 2017 г. 18:08
  • Я тоже так считал. Но видимо вопрос лежит немного в другой плоскости. К примеру после первого поля приходится вставлять дополнительные 4 байта, чтобы указатель, находящийся во втором поле, уместился в заданной области. А вот как сами разработчики решают вопрос без расширителей, я пока так и не понял.

    Не совсем понимаю что вы там добавляйте. Компилятор должен выровнять поля как требуется, ваша задача лишь правильно заполнить структуру. Покажите ваш код и в деталях опишите что именно происходит при вызове. Так же укажите значения препроцессора NTDDI_VERSION и UNICODE.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    14 ноября 2017 г. 19:31
  • Я вроде разобрался. Компилятор используемой мною среды разработки выполняет выравнивание struct и union до 1 байта, не зависимо от разрядности системы. Из-за этого и приходится заниматься самостоятельным выравниванием структуры. (((
    14 ноября 2017 г. 21:47
  • Я вроде разобрался. Компилятор используемой мною среды разработки выполняет выравнивание struct и union до 1 байта, не зависимо от разрядности системы. Из-за этого и приходится заниматься самостоятельным выравниванием структуры. (((
    А зачем? Не проще ли воспользоваться нормальным компилятором? 

    This posting is provided "AS IS" with no warranties, and confers no rights.

    14 ноября 2017 г. 21:58
  • Угу, под Windows программы лучше собирать с помощью Visual C++ или Intel C++. Первый можно установить без Visual Studio, и настроить стороннюю IDE на работу с ним. Собирать gcc или чем-то подобным бессмысленно, когда программа заточена под Windows.
    15 ноября 2017 г. 4:18
  • В данном случае требуется работа именно с конкретным компилятором, в противном случае придется писать dll. Но если без нее можно обойтись, то выбираю именно этот вариант. )))
    16 ноября 2017 г. 17:07
  • В данном случае требуется работа именно с конкретным компилятором, в противном случае придется писать dll. Но если без нее можно обойтись, то выбираю именно этот вариант. )))
    Ну если есть много свободного времени и/или структур не много, то почему бы и нет... 

    This posting is provided "AS IS" with no warranties, and confers no rights.

    16 ноября 2017 г. 17:21