есть система х64, разрабатывается приложение работы с БД
т.е. получается связка PRG.exe - драйвер доступа - клиент БД
я правильно понимаю, что все они должны быть либо х32, либо х64 ?
каша из модулей х32 и х64 недопустима, да?

в большинстве случаях, когда x32 работает на х64 - допустима.

в системе должны быть клиентские либы с разрядностью процесса их юзающего.

> KilkennyCat ©   (20.08.17 15:20) [1]

т.е. прога х32 может пользоваться драйвером х64, который обращается к клиентской библиотеке х32 ?

т.е. прога х32 может пользоваться драйвером х64, который обращается к клиентской библиотеке х32 ?

если сможешь сделать так,
что для дпр выставлен таргет x32 но при нажатиина  ф9
ты умудришься уговорить линковщик взять 64-битный adodb.dcu
то как раз будет такая ситуация.

прога 32, "драйвер" 64 а клиентские либы есть и те и те.

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

> ты умудришься уговорить линковщик взять 64-битный adodb.dcu

вообще-то имелся в виду драйвер, т.е. внешняя библиотека, а не unit из дельфи

внешняя библиотека это и есть драйвер, он же клиент бд.

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

> rrrrrr ©   (20.08.17 16:10) [7]

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

простой пример: exe -> dbxfb.dll -> fbclient.dll -> ...


> драйвер, он же клиент бд

даже не смешно
на одной машине драйверов могут быть десятки между прогой и слиентом СУБД

Мне удавалось прикрутить 64битный клиент оракла с 32битному приложению и оно работало. Но это... в общем, даже не пробуй.

Все exe и dll должны быть одинаковой разрядности.

ой зря ты ему про это рассказал.......
чувак-то с сурьезным настроем и бъет копытом

> чувак-то с сурьезным настроем и бъет копытом

в зеркало посмотри

меня же интересует беспроблемная конфигурация, а не гордиевы узлы
потому и пытаюсь подводные камни знать заранее, а не методом "уткнемся-разберемся"

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

.... но воткнуть в это способны не только лишь все.

ну вот у меня вчера чет х32 приложение не стало работать с х64 акцессовским чем-то-там-оле-12 на ви7х64. в то же время, всё прекрасно заработало с х32 от акцесса, на той же винде.
но мой случай - частный (одноразовая прога для) и поэтому с rrrrrr [2] полностью согласен.

> Мне удавалось прикрутить 64битный клиент оракла с 32битному
> приложению и оно работало. Но это... в общем, даже не пробуй.
>


Мне кажется ты лукавишь.

> Игорь Шевченко ©   (20.08.17 20:31) [15]

Нет, оно работало в продакшене долгое время. Может и сейчас работает, не знаю. То было во времена моей работе в Квесте. Я был молод и горяч :) Сделал   32хбитную обертку поверх 64битной oci.dll. 32хбитная dll-ка запускала в фоне 64битный процесс, который подгружал настоящую 64хбитную oci.dll и гоняла данные туда-сюда через межпроцессные всякие штуки.

Там в х32 и х64 oci.dll все функции одинаковые на самом деле, только разрядность другая. Так что ничего сверхъестественного, просто очень много муторной работы.

Имхо.
На 64-системе любое 64-приложение без проблем может использовать 32-библиотеки.

P.S.
Под приложением подразумевается любой исполняемый модуль как exe так и dll.

"использовать" - слово обтекаемое.

а так-то и у меня 32 битная винда использует 64 битные линуксовые библиотеки.
каждый день и без проблем.

Kerk ©   (20.08.17 22:26) [16]

Я потому и говорю - лукавишь. С маршаллингом и стабами, понятное дело, каждый сможет, COM-вызовы тоже через границы разрядности проходят :)

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

Можно чуть-чуть подробнее?

да все точно также как и у керка.
но не через суррогатный процесс-прокладку, а трехзвенку.

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

так как часть узлов - это линупс то можно сказать, что виндовый клиент получает данные библиотеками линукса (а он же их именно так и получает)

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

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

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

прививку от необходимости извращаться
путей легких нам не надо.

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

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

все так делают.

Надо просто избегать нативного кода, если есть такая возможность

> Надо просто избегать нативного кода, если есть такая возможность
вот что значит попробовать, сразу риторика меняется)

Я где-то в 2003м еще попробовал :)

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

Это как? А как же разный размер указателя?

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

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

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


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

Да все просто. Даже если предположить, что каким то чудом удалось загрузить 32 бит библиотеку dll в адресное пространство 64 бит процесса, то как быть с аргументами функций типа указатель, которые могут передаваться в экспортируемые dll функции. 64 бит приложение имеет 64 бит указатели, при передаче в качестве аргумента они обрежутся до 32 бит и будут указывать "непоймикуда".

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

Т.е. никаких "шлюзов", как было предусмотрено при переходе с 16 на 32 нынче не было создано?
Т.е. я конечно теоретически понимаю разницу между переходом с 16 на 32 и переходом с 32 на 64. 16-битная система всё равно работала реально с 32-битными адресами. А вот 32-битная система вроде работала только с 32-битными адресами.

Ну да. Похоже при переходе с 32 на 64 мелкомягие полностью наплевали на "обратною совместимость". Ну это их право.

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


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

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

Взаимно.

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

Иного и не ожидал.
Я по крайней мере честно признаюсь, что далеко не профи.

ну были санки 16<->32 в древности.

но сейчас-то зачем, да тем более в этом конкретном случае.
когда и драйвера есть для обеих платформ и dcc есть и такой и этакий.

>>А вот 32-битная система вроде работала только с 32-битными адресами.

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

Для понимания : https://www.livelib.ru/author/14929-endryu-tanenbaum