Конференция "Прочее" » разрядность модулей, работающих в связке под x64
 
  • Игорь Шевченко © (21.08.17 10:31) [20]
    Kerk ©   (20.08.17 22:26) [16]

    Я потому и говорю - лукавишь. С маршаллингом и стабами, понятное дело, каждый сможет, COM-вызовы тоже через границы разрядности проходят :)
  • Германн © (22.08.17 01:41) [21]

    > rrrrrrr ©   (21.08.17 08:40) [19]
    >
    > "использовать" - слово обтекаемое.
    >
    > а так-то и у меня 32 битная винда использует 64 битные линуксовые
    > библиотеки.
    > каждый день и без проблем.

    Можно чуть-чуть подробнее?
  • rrrrrrr © (22.08.17 08:58) [22]
    да все точно также как и у керка.
    но не через суррогатный процесс-прокладку, а трехзвенку.

    зоопарк конкретных sql серверов описан в метаданных системы.
    по сети раскиданы узлы обрабатывающие запросы
    траспорт от клиента до них - шттп
    от них до sql-серверов - нативные клиентские библиотеки.
    результат отдается в json/xml/cds datapacket (в зависимости от того кто за ним пришел)

    так как часть узлов - это линупс то можно сказать, что виндовый клиент получает данные библиотеками линукса (а он же их именно так и получает)
  • Чемпаркароке © (22.08.17 14:05) [23]

    > Kerk ©   (20.08.17 22:26) [16]

    такие хаки приходилось делать еще во времена win16<->win32
    надеялся, что с тех пор в MS уже изобрели прививку от необходимости извращаться
    но похоже "От дурного семени не жди доброго племени", все повторяется

    вот интересно, через пару-тройку лет захотится им сделать х128, всё опять по-новой?
  • rrrrrrr © (22.08.17 15:14) [24]
    прививку от необходимости извращаться
    путей легких нам не надо.

    захотится им сделать х128, всё опять по-новой?

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

    все так делают.
  • Kerk © (22.08.17 15:20) [25]
    Надо просто избегать нативного кода, если есть такая возможность
  • ухты © (22.08.17 16:23) [26]

    > Надо просто избегать нативного кода, если есть такая возможность
    вот что значит попробовать, сразу риторика меняется)
  • Kerk © (22.08.17 16:48) [27]
    Я где-то в 2003м еще попробовал :)
  • DVM © (22.08.17 22:01) [28]

    > Германн ©   (21.08.17 01:46) [17]
    > Имхо.
    > На 64-системе любое 64-приложение без проблем может использовать
    > 32-библиотеки.

    Это как? А как же разный размер указателя?
  • Германн © (23.08.17 01:59) [29]

    > DVM ©   (22.08.17 22:01) [28]
    >
    >
    > > Германн ©   (21.08.17 01:46) [17]
    > > Имхо.
    > > На 64-системе любое 64-приложение без проблем может использовать
    > > 32-библиотеки.
    >
    > Это как? А как же разный размер указателя?

    Может я что-то не понимаю. Как программист я уже давно ушел на пенсию, тем более что программистом я и не работал почти никогда.
    Но при чём тут размер указателя?
  • DVM © (23.08.17 21:43) [30]

    > Германн ©   (23.08.17 01:59) [29]


    > Но при чём тут размер указателя?

    Да все просто. Даже если предположить, что каким то чудом удалось загрузить 32 бит библиотеку dll в адресное пространство 64 бит процесса, то как быть с аргументами функций типа указатель, которые могут передаваться в экспортируемые dll функции. 64 бит приложение имеет 64 бит указатели, при передаче в качестве аргумента они обрежутся до 32 бит и будут указывать "непоймикуда".
  • Германн © (24.08.17 02:04) [31]

    > DVM ©   (23.08.17 21:43) [30]

    Т.е. никаких "шлюзов", как было предусмотрено при переходе с 16 на 32 нынче не было создано?
    Т.е. я конечно теоретически понимаю разницу между переходом с 16 на 32 и переходом с 32 на 64. 16-битная система всё равно работала реально с 32-битными адресами. А вот 32-битная система вроде работала только с 32-битными адресами.
  • Германн © (24.08.17 02:20) [32]
    Ну да. Похоже при переходе с 32 на 64 мелкомягие полностью наплевали на "обратною совместимость". Ну это их право.
  • Игорь Шевченко © (24.08.17 10:26) [33]

    > Как программист я уже давно ушел на пенсию, тем более что
    > программистом я и не работал почти никогда.


    Ты эту мантру повторяй про себя каждый раз, когда захочешь написать что-то на форум.
  • Германн © (25.08.17 02:42) [34]

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

    Взаимно.
  • Германн © (25.08.17 20:33) [35]

    > Удалено модератором
    >  

    Иного и не ожидал.
    Я по крайней мере честно признаюсь, что далеко не профи.
  • rrrrrr © (25.08.17 20:53) [36]
    ну были санки 16<->32 в древности.

    но сейчас-то зачем, да тем более в этом конкретном случае.
    когда и драйвера есть для обеих платформ и dcc есть и такой и этакий.
  • tesseract © (06.09.17 05:02) [37]
    >>А вот 32-битная система вроде работала только с 32-битными адресами.

    Motorola и Intel работали по разному. Pentium имел таки 64-битную шину данных. Мог работать с 64-битными адресами, и 64-битными  real числами. PAE windows nt  спокойно работала с прямой 48-битной адресацией. Правда из-за совместимости до 3-х гб на процесс.  

    Для понимания : https://www.livelib.ru/author/14929-endryu-tanenbaum
 
Конференция "Прочее" » разрядность модулей, работающих в связке под x64
Есть новые Нет новых   [134430   +2][b:0][p:0.001]