headers
Knut St. Osmundsen | 3 Mar 2007 22:59
Favicon

Re: DLL startup

James Moe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
>   I changed the library code of a module to use the DLL instead of a
> static library. Specifically I am using OpenSSL: <ssl.dll> and
> <crypto.dll>. The DLLs are not necessarily in LIBPATH.

If you don't use dlopen / DosLoadModule and dlsym / DosQueryProcAddr all 
the DLLs has to be in the *LIBPATHs. That's the way the loader works.

>   The program has code to load the DLLs during initialization. But the
> program now refuses to start because it cannot find SSL. There appears to
> be some runtime startup code that is executed before main() is entered.

Yes, most DLLs has a DLL_InitTerm entrypoint that's executed after 
they've been loaded to initialized the CRT and other things. All this 
has to be executed before main(). The same goes for static initializers 
(global objects and such like in C++). That's part of how the DLLs and 
EXE works.

>   The startup ignores BEGINLIBPATH.

No, it doesn't. Statically linked DLLs dependencies are resolved before 
any code is executed in the process by the OS/2 kernel.

>   Is that startup added by the compiler? If so, is there a way to prevent
> it from running?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Knut St. Osmundsen | 3 Mar 2007 23:01
Favicon

Re: UNC path names

James Moe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Knut St. Osmundsen wrote:
>> James Moe wrote:
>>   Does libc061-csd1 offer any support of UNC (Universal Naming Convention)
>> for paths and filenames?
>>
>> Yes of course. But let me know if something is buggy.
>>
>   chdir() returns 0 indicating success but the working directory does not
> actually change.
>   The test program below demonstrates the problem. The UNC path is valid
> for our network. Here is the output from the test program:
> 
> chdir(\\sma-server1\graphics\bmp) succeeded.
> cwd is [G:/tmp]
> 
> 
> - ----[ test program ]----
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> 
> int main () {
>     const char uncname[] = "\\\\sma-server1\\graphics\\bmp";
> 
>     if (0 != chdir(uncname))
(Continue reading)

Permalink | Reply | 3 comments |
headers
Knut St. Osmundsen | 3 Mar 2007 23:19
Favicon

Re: malloc() problem

James Moe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
>   I've run into a curious problem with malloc(). It would seem it has
> difficulty with frequent allocation requests when the sizes are less than
> 16 bytes. The "difficulty" is a program crash.
>   I have added the following to a main header and the crashes have gone away.
> #define malloc(sz) malloc((((sz) < 16) ? 16 : sz))
> 
>   There is only one code module that makes repeated allocations less than
> 16 bytes so I am not totally certain it is a library problem.
>   The failures are consistent but the pattern is not obvious. In one case
> an allocation of 4 bytes succeeded, but a following one of 5 bytes failed.
> In another case a 4 byte allocation succeeded but a following 4 byte one
> failed. The malloc() calls were not necessarily consecutive.

The heap code is from emx and I can't remember having seen any similar 
issues with emx nor libc. There are some minor changes from emx to libc, 
these include some more mmx / see friendly alignment policies. Of course 
there might be a long standing bug or a regression introduced in the 
libc code, but honestly, if a problem goes away by mallocing more memory 
for certain block types I tend to suspect heap corruption caused by the 
application first. (Which reminds me, I have to integrate that electric 
fence heap properly so this kind of stuff can easily be debugged.)

You might try narrowing down the sizes that triggers the issue:
#define malloc(sz) malloc(   (sz) < 16 \
                           && (sz) != x \
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Moe | 4 Mar 2007 07:28
Favicon

Re: DLL startup


Knut St. Osmundsen wrote:
> 
>>   The program has code to load the DLLs during initialization. But the
>> program now refuses to start because it cannot find SSL. There appears to
>> be some runtime startup code that is executed before main() is entered.
> 
> Yes, most DLLs has a DLL_InitTerm entrypoint that's executed after 
> they've been loaded to initialized the CRT and other things. All this 
> has to be executed before main(). The same goes for static initializers 
> (global objects and such like in C++). That's part of how the DLLs and 
> EXE works.
> 
  I guess OpenSSL must have a DLL_InitTerm then. I do use DosLoadModule()
after the program starts but that doesn't help much if the program never
starts.

>>   The startup ignores BEGINLIBPATH.
> 
> No, it doesn't. Statically linked DLLs dependencies are resolved before 
> any code is executed in the process by the OS/2 kernel.
> 
  Yes, I must have made a typo because it works as expected now.

--
jimoe (at) sohnen-moe (dot) com
Permalink | Reply | 0 comments |
headers
Andrew MacIntyre | 4 Mar 2007 09:53
Picon
Picon

Re: malloc() problem

Knut St. Osmundsen wrote:
> James Moe wrote:
>>   I've run into a curious problem with malloc(). It would seem it has
>> difficulty with frequent allocation requests when the sizes are less than
>> 16 bytes. The "difficulty" is a program crash.
>>   I have added the following to a main header and the crashes have 
>> gone away.
>> #define malloc(sz) malloc((((sz) < 16) ? 16 : sz))
>>
>>   There is only one code module that makes repeated allocations less than
>> 16 bytes so I am not totally certain it is a library problem.
>>   The failures are consistent but the pattern is not obvious. In one case
>> an allocation of 4 bytes succeeded, but a following one of 5 bytes 
>> failed.
>> In another case a 4 byte allocation succeeded but a following 4 byte one
>> failed. The malloc() calls were not necessarily consecutive.
> 
> The heap code is from emx and I can't remember having seen any similar 
> issues with emx nor libc. There are some minor changes from emx to libc, 
> these include some more mmx / see friendly alignment policies. Of course 
> there might be a long standing bug or a regression introduced in the 
> libc code, but honestly, if a problem goes away by mallocing more memory 
> for certain block types I tend to suspect heap corruption caused by the 
> application first. (Which reminds me, I have to integrate that electric 
> fence heap properly so this kind of stuff can easily be debugged.)
> 
> You might try narrowing down the sizes that triggers the issue:
> #define malloc(sz) malloc(   (sz) < 16 \
>                           && (sz) != x \
>                          [&& (sz) != y [..]] \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brendan Oakley | 5 Mar 2007 19:30
Picon

Re: UNC path names

The behavior might depends on the program. On Windows different shells
behave differently. In Windows XP's cmd.exe:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\HP_Owner>cd \\eeyore\brendan
'\\eeyore\brendan'
CMD does not support UNC paths as current directories.

In 4NT:

4NT  3.01A   Windows NT 5.00
Copyright 1988-1998  Rex Conn & JP Software Inc.  All Rights Reserved

[c:\documents and settings\brendan]cd \\c0web100\d\

[c:\documents and settings\brendan]

See CMD blames itself for the limitation. 4NT does not give an error
message at all, but whether it has actually done anything I can't
tell. Maybe it's like 'cd' on a drive other than the current one, but
how to refer to that drive I don't know.

IIRC on libc ash and bash, the 'cd' command changes the current drive
as well as the current directory, unlike OS/2's cmd which only changes
the current directory on the referenced drive, leaving the current
drive alone.

My point is that whether this behavior of chdir() is a bug or not
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brendan Oakley | 5 Mar 2007 19:37
Picon

Re: UNC path names

Just remembered how to change to a UNC path in 4NT. Thereafter 'cd'
does work. For what it's worth.

4NT  3.01A   Windows NT 5.00
Copyright 1988-1998  Rex Conn & JP Software Inc.  All Rights Reserved

[c:\documents and settings\brendan]\\c0web100\d\

[\\c0web100\d]
[\\c0web100\d]cd \\c0web100\d\btmp

[\\c0web100\d\btmp]

Brendan
Permalink | Reply | 1 comment |
headers
Brendan Oakley | 5 Mar 2007 20:05
Picon

Re: UNC path names

This is from the Visual Basic documentation on MSDN. I found no
information in Visual C. I interpret this to mean the current behavior
of libc, as described, matches the documented behavior on Windows. But
again, there may be reason to define it differently.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcn7/html/vbconIntroductionToFileSystemObjectModel.asp

App.Path, ChDir, ChDrive, and CurDir

If you use the Path property (App.Path), the ChDrive and ChDir
statements, or the CurDir function, be aware that they may return a
Universal Naming Convention (UNC) path (that is, one beginning with
\\Server\Share...) rather than a drive path (such as e:\Folder),
depending on how you run your program or project.

App.Path returns a UNC path when:

    * You run a project after loading it from a network share, even if
the network share is mapped to a drive letter.
    * You run a compiled executable file from a network share (but
only if it is run using a UNC path).

ChDrive cannot handle UNC paths, and it raises an error when App.Path
returns one. You can handle this error by adding On Error Resume Next
before the ChDrive statement, or by testing the first two characters
of App.Path to see if they are backslashes.

The command prompt always has a drive path for the current directory,
so CurDir is set to a drive path. ChDir does not raise an error, but
it fails to change the directory from a drive path to a UNC path. The
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Moe | 5 Mar 2007 21:58
Favicon

Library names


Hello,
  I recall a similar discussion somewhere about this but I cannot find a
reference to it.
  By default gcc outputs function names prepended with an underscore. For
DLLs this is not a good thing. Is there a compiler switch that overrides
the naming behavior?
  There are methods for modifying the output for individual functions
(_System, declspec, __attribute__). But when there are 1000s of functions
this is not practical.

--
jimoe (at) sohnen-moe (dot) com
Permalink | Reply | 1 comment |
headers
Knut St. Osmundsen | 6 Mar 2007 16:03
Favicon

Re: Library names

James Moe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
>   I recall a similar discussion somewhere about this but I cannot find a
> reference to it.
>   By default gcc outputs function names prepended with an underscore. For
> DLLs this is not a good thing. Is there a compiler switch that overrides
> the naming behavior?

The simple answer is, no there isn't.

>   There are methods for modifying the output for individual functions
> (_System, declspec, __attribute__). But when there are 1000s of functions
> this is not practical.

That's what everyone else does on OS/2.

Take a look at http://svn.netlabs.org/libc/wiki/Faq#Callingconventions 
for more details.

Kind Regards,
  knut
Permalink | Reply | 0 comments |

Gmane