On 12/14/2011 03:14 PM, Rainer Jung wrote:
On 14.12.2011 11:09, Mladen Turk wrote:
On 12/14/2011 04:25 AM, William A. Rowe Jr. wrote:
> Reposting for Graham's benefit, who likely skimmed over this;
>
> On 12/11/2011 1:49 PM, Rainer Jung wrote:
>>
>> - Windows Build system:
>> - all *.dep and *.mak files are missing
>> - in test/testutildll.dsp the probably obsolete string "NT" is
>> by the possibly similarly obsolete "9x"
>> - change of base addresses in some dsp file (might be OK)
>
> Bill asks, can you be more specific on the 3rd bullet? Because we aim
> for binary compatibility, that would be a (regrettable) regression. As
> I was traveling, I had no chance to look at this candidate.
>
If you look at old version multiple modules has the same base address
which was probably caused by simple copy/paste.
Eg, multiple dbd modules had the same base address (0x6EF00000)
dmb modules had the same address as dbd modules.
I only made sure they are unique, because if you try to load the
second dll with the same base address it'll get random one.
Changes rel. 1.3.12 I observed:
base address 0x6EF00000 -> 0x6EF60000 apr_dbd_freetds.dsp
base address 0x6EF00000 -> 0x6F000000 apr_dbm_db.dsp
base address 0x6EF10000 -> 0x6F010000 apr_dbm_gdbm.dsp
Right, as you see apr_dbd_freetds and apr_dbm_db had the
same base address.
apr_dbm_gdbm had the same address as apr_dbd_odbc module.
That was wrong at the first place, so hardly any regression.
Regards
--
^TM
