Discussion:
The Open Watcom Fork project has its own 2.0 now
(too old to reply)
Lynn McGuire
2014-02-13 22:51:33 UTC
Permalink
Raw Message
The Open Watcom unofficial fork project has its
own version 2.0 now:
http://sourceforge.net/projects/openwatcom/
and
http://open-watcom.github.io/open-watcom/

I guess this is Jiri Malak.

Below is list of main differences against oficial Open Watcom:
1. New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
2. Code generator properly initialize pointers by DLL symbol addresses
3. DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS
4. OW is ported to 64-bit hosts (WIN64, Linux X64)
5. Librarian support X64 CPU object modules and libraries
6. RDOS 32-bit C run-time compact memory model libraries are fixed
7. Resource compiler and Resource editors support WIN64 executables
8. OW text editor is now self containing, it can be used as standalone tool without any requirements for any additional files or
configuration
9. Broken C++ compiler pre-compiled header template support is fixed
10. Many C++ compiler crashes are fixed
11. Debugger has no length limit for any used environment variable

Lynn
Javier Gutiérrez
2014-02-14 12:10:37 UTC
Permalink
Raw Message
I have been following its development since a couple of months ago, and
think Jiri's efforts are excelent.
Post by Lynn McGuire
The Open Watcom unofficial fork project has its
http://sourceforge.net/projects/openwatcom/
and
http://open-watcom.github.io/open-watcom/
I guess this is Jiri Malak.
1. New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
2. Code generator properly initialize pointers by DLL symbol addresses
3. DOS version of tools now support long file names (LFN) if appropriate
LFN driver is loaded by DOS
4. OW is ported to 64-bit hosts (WIN64, Linux X64)
5. Librarian support X64 CPU object modules and libraries
6. RDOS 32-bit C run-time compact memory model libraries are fixed
7. Resource compiler and Resource editors support WIN64 executables
8. OW text editor is now self containing, it can be used as standalone
tool without any requirements for any additional files or configuration
9. Broken C++ compiler pre-compiled header template support is fixed
10. Many C++ compiler crashes are fixed
11. Debugger has no length limit for any used environment variable
Lynn
--
Usando el cliente de correo de Opera: http://www.opera.com/mail/
Lynn McGuire
2014-02-14 20:48:55 UTC
Permalink
Raw Message
I have been following its development since a couple of months ago, and think Jiri's efforts are excelent.
Post by Lynn McGuire
The Open Watcom unofficial fork project has its
http://sourceforge.net/projects/openwatcom/
and
http://open-watcom.github.io/open-watcom/
I guess this is Jiri Malak.
1. New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
2. Code generator properly initialize pointers by DLL symbol addresses
3. DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS
4. OW is ported to 64-bit hosts (WIN64, Linux X64)
5. Librarian support X64 CPU object modules and libraries
6. RDOS 32-bit C run-time compact memory model libraries are fixed
7. Resource compiler and Resource editors support WIN64 executables
8. OW text editor is now self containing, it can be used as standalone tool without any requirements for any additional files or
configuration
9. Broken C++ compiler pre-compiled header template support is fixed
10. Many C++ compiler crashes are fixed
11. Debugger has no length limit for any used environment variable
Lynn
Is he picking up code changes from this site
or just his own?

Thanks,
Lynn
Javier Gutiérrez
2014-02-15 10:23:24 UTC
Permalink
Raw Message
It picked some initial code, I guess at the begining of the fork, and I =
am =

not sure if after that it applied some code base updates with latest =

commits in Perfoce. Hope so, in orde to join efforts on both sides.

Anyway, according to the GIT log =

(https://github.com/open-watcom/open-watcom-v2/commits/master?page=3D3) =
I do =

not see that.

Regards.
Post by Lynn McGuire
I have been following its development since a couple of months ago, a=
nd =
Post by Lynn McGuire
think Jiri's efforts are excelent.
Post by Lynn McGuire
The Open Watcom unofficial fork project has its
http://sourceforge.net/projects/openwatcom/
and
http://open-watcom.github.io/open-watcom/
I guess this is Jiri Malak.
1. New 2-phase build system, OW can be build by platform native C/C+=
+ =
Post by Lynn McGuire
Post by Lynn McGuire
compiler or by itself
2. Code generator properly initialize pointers by DLL symbol address=
es
Post by Lynn McGuire
Post by Lynn McGuire
3. DOS version of tools now support long file names (LFN) if =
appropriate LFN driver is loaded by DOS
4. OW is ported to 64-bit hosts (WIN64, Linux X64)
5. Librarian support X64 CPU object modules and libraries
6. RDOS 32-bit C run-time compact memory model libraries are fixed
7. Resource compiler and Resource editors support WIN64 executables
8. OW text editor is now self containing, it can be used as standalo=
ne =
Post by Lynn McGuire
Post by Lynn McGuire
tool without any requirements for any additional files or
configuration
9. Broken C++ compiler pre-compiled header template support is fixed=
10. Many C++ compiler crashes are fixed
11. Debugger has no length limit for any used environment variable
Lynn
Is he picking up code changes from this site
or just his own?
Thanks,
Lynn
-- =

Usando el cliente de correo de Opera: http://www.opera.com/mail/
Jiri Malak
2014-02-16 01:12:49 UTC
Permalink
Raw Message
It picked some initial code, I guess at the begining of the fork, and I am
not sure if after that it applied some code base updates with latest
commits in Perfoce. Hope so, in orde to join efforts on both sides.
Anyway, according to the GIT log
(https://github.com/open-watcom/open-watcom-v2/commits/master?page=3) I do
not see that.
Regards.
Post by Lynn McGuire
Post by Javier Gutiérrez
I have been following its development since a couple of months ago, and
think Jiri's efforts are excelent.
Post by Lynn McGuire
The Open Watcom unofficial fork project has its
http://sourceforge.net/projects/openwatcom/
and
http://open-watcom.github.io/open-watcom/
I guess this is Jiri Malak.
1. New 2-phase build system, OW can be build by platform native C/C++
compiler or by itself
2. Code generator properly initialize pointers by DLL symbol addresses
3. DOS version of tools now support long file names (LFN) if
appropriate LFN driver is loaded by DOS
4. OW is ported to 64-bit hosts (WIN64, Linux X64)
5. Librarian support X64 CPU object modules and libraries
6. RDOS 32-bit C run-time compact memory model libraries are fixed
7. Resource compiler and Resource editors support WIN64 executables
8. OW text editor is now self containing, it can be used as standalone
tool without any requirements for any additional files or
configuration
9. Broken C++ compiler pre-compiled header template support is fixed
10. Many C++ compiler crashes are fixed
11. Debugger has no length limit for any used environment variable
Lynn
Is he picking up code changes from this site
or just his own?
Initial base is at change 37426 (OW 1.9).
All important changes after 37426 were aplied to V2 fork.
Some changes were not included because they are problematic or introduce
some problem.

Anyway V2 fork is too different from Perforce now that back nerge to OW 1.9
has no much sense.
I think that oficial OW is now realy dead.

Jiri
Lynn McGuire
2014-02-17 17:42:57 UTC
Permalink
Raw Message
Post by Jiri Malak
Initial base is at change 37426 (OW 1.9).
All important changes after 37426 were aplied to V2 fork.
Some changes were not included because they are problematic or introduce
some problem.
Anyway V2 fork is too different from Perforce now that back nerge to OW 1.9
has no much sense.
I think that oficial OW is now realy dead.
Jiri
Definitely not much action in Open Watcom.

What tests did you run on your branch to
verify that there are no problems?

Thanks,
Lynn
Jiri Malak
2014-02-17 23:50:05 UTC
Permalink
Raw Message
Post by Lynn McGuire
Post by Jiri Malak
Initial base is at change 37426 (OW 1.9).
All important changes after 37426 were aplied to V2 fork.
Some changes were not included because they are problematic or introduce
some problem.
Anyway V2 fork is too different from Perforce now that back nerge to OW
1.9 has no much sense.
I think that oficial OW is now realy dead.
Jiri
Definitely not much action in Open Watcom.
What tests did you run on your branch to
verify that there are no problems?
All OW regression test for C compiler, C++ compiler, F77 compiler and WASM
which are located in ctest, f77test, plustest and wasmtest directories.
It tests only core utilities, no GUI utilities.
These I am testing randomly, only base functionality.

Jiri
Lynn McGuire
2014-02-18 17:06:47 UTC
Permalink
Raw Message
Post by Jiri Malak
Post by Lynn McGuire
Post by Jiri Malak
Initial base is at change 37426 (OW 1.9).
All important changes after 37426 were aplied to V2 fork.
Some changes were not included because they are problematic or introduce
some problem.
Anyway V2 fork is too different from Perforce now that back nerge to OW
1.9 has no much sense.
I think that oficial OW is now realy dead.
Jiri
Definitely not much action in Open Watcom.
What tests did you run on your branch to
verify that there are no problems?
All OW regression test for C compiler, C++ compiler, F77 compiler and WASM
which are located in ctest, f77test, plustest and wasmtest directories.
It tests only core utilities, no GUI utilities.
These I am testing randomly, only base functionality.
Jiri
Thanks!

So the sourceforge installer has everything in
it now? C, C++, F77 and WASM?

Lynn
Jiri Malak
2014-02-19 01:49:12 UTC
Permalink
Raw Message
Post by Lynn McGuire
Post by Jiri Malak
Post by Lynn McGuire
Post by Jiri Malak
Initial base is at change 37426 (OW 1.9).
All important changes after 37426 were aplied to V2 fork.
Some changes were not included because they are problematic or
introduce some problem.
Anyway V2 fork is too different from Perforce now that back nerge to OW
1.9 has no much sense.
I think that oficial OW is now realy dead.
Jiri
Definitely not much action in Open Watcom.
What tests did you run on your branch to
verify that there are no problems?
All OW regression test for C compiler, C++ compiler, F77 compiler and
WASM which are located in ctest, f77test, plustest and wasmtest
directories. It tests only core utilities, no GUI utilities.
These I am testing randomly, only base functionality.
Jiri
Thanks!
So the sourceforge installer has everything in
it now? C, C++, F77 and WASM?
Yes, it is full features installers (including documentation).

Jiri
J
2014-03-12 17:16:44 UTC
Permalink
Raw Message
They tell me that this is not officially supported. Yay.
J
2014-02-21 05:15:43 UTC
Permalink
Raw Message
Post by Lynn McGuire
The Open Watcom unofficial fork project has its
http://sourceforge.net/projects/openwatcom/
and
http://open-watcom.github.io/open-watcom/
I guess this is Jiri Malak.
1. New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
2. Code generator properly initialize pointers by DLL symbol addresses
3. DOS version of tools now support long file names (LFN) if appropriate
LFN driver is loaded by DOS
4. OW is ported to 64-bit hosts (WIN64, Linux X64)
5. Librarian support X64 CPU object modules and libraries
6. RDOS 32-bit C run-time compact memory model libraries are fixed
7. Resource compiler and Resource editors support WIN64 executables
8. OW text editor is now self containing, it can be used as standalone
tool without any requirements for any additional files or configuration
9. Broken C++ compiler pre-compiled header template support is fixed
10. Many C++ compiler crashes are fixed
11. Debugger has no length limit for any used environment variable
Lynn
Very nice :)
I was just thinking bout y'all

I'll test it soon enough ; but any chance this code works?

struct name_and_id_params
{
CTEXTSTR name;
THREAD_ID thread;
};

struct name_and_id_params params = { name, thread };

instead of
struct name_and_id_params params;
params.name = name;
params.thread = thread;


(compile error; required constant expression)

G'day
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-02-21 05:56:14 UTC
Permalink
Raw Message
Post by J
Post by Lynn McGuire
The Open Watcom unofficial fork project has its
http://sourceforge.net/projects/openwatcom/
and
http://open-watcom.github.io/open-watcom/
I guess this is Jiri Malak.
1. New 2-phase build system, OW can be build by platform native C/C++
compiler or by itself
2. Code generator properly initialize pointers by DLL symbol addresses
3. DOS version of tools now support long file names (LFN) if
appropriate LFN driver is loaded by DOS
4. OW is ported to 64-bit hosts (WIN64, Linux X64)
5. Librarian support X64 CPU object modules and libraries
6. RDOS 32-bit C run-time compact memory model libraries are fixed
7. Resource compiler and Resource editors support WIN64 executables
8. OW text editor is now self containing, it can be used as standalone
tool without any requirements for any additional files or configuration
9. Broken C++ compiler pre-compiled header template support is fixed
10. Many C++ compiler crashes are fixed
11. Debugger has no length limit for any used environment variable
Lynn
Very nice :)
I was just thinking bout y'all
I'll test it soon enough ; but any chance this code works?
struct name_and_id_params
{
CTEXTSTR name;
THREAD_ID thread;
};
struct name_and_id_params params = { name, thread };
instead of
struct name_and_id_params params;
params.name = name;
params.thread = thread;
(compile error; required constant expression)
G'day
Nope; the above code still fails...


making a shared library without entry points also still fails.....

Linking C shared library application_delay.module
Error! No exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir\all)
returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making (all) returned a bad status
Error(E02): Make execution terminated


I've been adding
#if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif

Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jiri Malak
2014-02-21 18:15:32 UTC
Permalink
Raw Message
If you give me more details or reference to OW bugzilla I can fix it.

Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module
Error! No exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir\all)
returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making (all) returned a bad status
Error(E02): Make execution terminated
I've been adding
#if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
J
2014-02-22 06:01:32 UTC
Permalink
Raw Message
On Fri, 21 Feb 2014 10:15:32 -0800, Jiri Malak <***@gmail.com>
wrote:

I see; I haven't tracked this down I think.... It's part of the automatic
build system (CMake) really, but I ran into it before then also... It
runs something like this...

--- test.bat ---
echo void f( void ){ } > dll.c
wcc386 -bd -br dll.c
wlink system nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---

(create a file, dll.c, with a function in it)
compile the source
link the source

use wlib to build the symbol table

wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"

------------- Test Output ------------

M:\tmp\watcom\test_nosyms>mk.bat


M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c

M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c
Open Watcom C x86 32-bit Optimizing Compiler
Version 2.0 beta Feb 19 2014 22:40:42 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors
Code size: 11

M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT dynamic link library

M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'

M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module
Error! No exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir\all)
returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making (all) returned a bad status
Error(E02): Make execution terminated
I've been adding
#if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jiri Malak
2014-02-22 16:03:39 UTC
Permalink
Raw Message
I don't see any problem.
You try to create DLL without any export, then wlib report it as error if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.

Jiri
Post by J
I see; I haven't tracked this down I think.... It's part of the automatic
build system (CMake) really, but I ran into it before then also... It
runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c
wcc386 -bd -br dll.c
wlink system nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source
link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c
Open Watcom C x86 32-bit Optimizing Compiler
Version 2.0 beta Feb 19 2014 22:40:42 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors
Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module
Error! No exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir\all)
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making (all) returned a bad status
Error(E02): Make execution terminated
I've been adding
#if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
J
2014-02-25 00:34:37 UTC
Permalink
Raw Message
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as error if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Why?
If I have static classes declared, they should still get initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
I see; I haven't tracked this down I think.... It's part of the automatic
build system (CMake) really, but I ran into it before then also... It
runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c
wcc386 -bd -br dll.c
wlink system nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source
link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c
Open Watcom C x86 32-bit Optimizing Compiler
Version 2.0 beta Feb 19 2014 22:40:42 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors
Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module
Error! No exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir\all)
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making (all) returned a bad status
Error(E02): Make execution terminated
I've been adding
#if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-02-25 00:40:28 UTC
Permalink
Raw Message
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as error if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")

....

#define PRIORITY_PRELOAD(name,priority) static void
pastejunk(schedule_,name)(void); static void CPROC name(void); \
static struct rt_init __based(__segname("XI"))
pastejunk(name,_ctor_label)={0,(DEADSTART_PRELOAD_PRIORITY-1),pastejunk(schedule_,name)};
\
static void pastejunk(schedule_,name)(void) { \
RegisterPriorityStartupProc(
name,TOSTR(name),priority,&pastejunk(name,_ctor_label),WIDE__FILE__,__LINE__
);\
} \
void name(void)

PRIORITY_PRELOAD( InitMyCode )
{
/* do startup init here */
}

But all of these are just functions, they are not DLL exports...
Post by J
Why?
If I have static classes declared, they should still get initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
I see; I haven't tracked this down I think.... It's part of the automatic
build system (CMake) really, but I ran into it before then also... It
runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c
wcc386 -bd -br dll.c
wlink system nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source
link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c
Open Watcom C x86 32-bit Optimizing Compiler
Version 2.0 beta Feb 19 2014 22:40:42 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors
Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module
Error! No exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir\all)
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making (all) returned a bad status
Error(E02): Make execution terminated
I've been adding
#if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-02-25 00:43:14 UTC
Permalink
Raw Message
Post by J
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as error if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
(Sorry I mean data, not code, it's just struct rt_init 's)
Post by J
....
#define PRIORITY_PRELOAD(name,priority) static void
pastejunk(schedule_,name)(void); static void CPROC name(void); \
static struct rt_init __based(__segname("XI"))
pastejunk(name,_ctor_label)={0,(DEADSTART_PRELOAD_PRIORITY-1),pastejunk(schedule_,name)};
\
static void pastejunk(schedule_,name)(void) { \
RegisterPriorityStartupProc(
name,TOSTR(name),priority,&pastejunk(name,_ctor_label),WIDE__FILE__,__LINE__
);\
} \
void name(void)
PRIORITY_PRELOAD( InitMyCode )
{
/* do startup init here */
}
But all of these are just functions, they are not DLL exports...
Post by J
Why?
If I have static classes declared, they should still get initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
I see; I haven't tracked this down I think.... It's part of the automatic
build system (CMake) really, but I ran into it before then also... It
runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c
wcc386 -bd -br dll.c
wlink system nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source
link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c
Open Watcom C x86 32-bit Optimizing Compiler
Version 2.0 beta Feb 19 2014 22:40:42 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors
Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module
Error! No exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir\all)
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated
Error(E42): Last command making (all) returned a bad status
Error(E02): Make execution terminated
I've been adding
#if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jiri Malak
2014-02-25 06:04:38 UTC
Permalink
Raw Message
I understand what you are trying to do, even if it is horible.
The problem is with incorrect use of OW tools.

Explain me why you are creating import library for DLL without any entry
point? What sense it has?
OW reports error correctly. Do you think it is a bug?
Why? Because CMake is not happy?

Solution is simple don't try to create import library for this kind of DLL
(without any entry point) because it has no sense.

Jiri
Post by J
Post by J
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as
error if generate import library.
If you want export some symbol from DLL you must specify it, either
to compiler by __declspec(dllexport) or to linker by export
directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
(Sorry I mean data, not code, it's just struct rt_init 's)
Post by J
....
#define PRIORITY_PRELOAD(name,priority) static void
pastejunk(schedule_,name)(void); static void CPROC name(void); \
static struct rt_init __based(__segname("XI"))
pastejunk(name,_ctor_label)={0,(DEADSTART_PRELOAD_PRIORITY-1),pastejunk
(schedule_,name)};
Post by J
Post by J
\
static void pastejunk(schedule_,name)(void) { \
RegisterPriorityStartupProc(
name,TOSTR(name),priority,&pastejunk
(name,_ctor_label),WIDE__FILE__,__LINE__
Post by J
Post by J
);\
} \
void name(void)
PRIORITY_PRELOAD( InitMyCode )
{
/* do startup init here */
}
But all of these are just functions, they are not DLL exports...
Post by J
Why?
If I have static classes declared, they should still get initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
On Fri, 21 Feb 2014 10:15:32 -0800, Jiri Malak
I see; I haven't tracked this down I think.... It's part of the
automatic build system (CMake) really, but I ran into it before then
also... It runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c wcc386 -bd -br dll.c wlink system
nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c Open Watcom C x86
32-bit Optimizing Compiler Version 2.0 beta Feb 19 2014 22:40:42
(32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
loading object files searching libraries creating a Windows NT
dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module Error! No
exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a
bad status Error(E02): Make execution terminated Error(E42): Last
command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir
\all)
Post by J
Post by J
Post by J
Post by Jiri Malak
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated Error(E42): Last command
making (all) returned a bad status Error(E02): Make execution
terminated
I've been adding #if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
J
2014-02-26 10:48:11 UTC
Permalink
Raw Message
Post by Jiri Malak
I understand what you are trying to do, even if it is horible.
The problem is with incorrect use of OW tools.
Explain me why you are creating import library for DLL without any entry
point? What sense it has?
OW reports error correctly. Do you think it is a bug?
Why? Because CMake is not happy?
Solution is simple don't try to create import library for this kind of DLL
(without any entry point) because it has no sense.
--- other valid code for DLLL ---
void InitFunc()
{}

class init_me {
public:
init_me() {
__declspec(dllimport) RegisterMyInit( void(*)(void));
RegisterMyInit( InitFunc );
}
} runme ;

----------------------------------------

// something like this in the core DLL...

LoadLibarary( "Dll.dll" );
/*class initializes*/

for( func = init_funcs; func; func = func->next )
func->init(); /* run InitFunc which was registered */


--------------------------------------
Again I don't need a dll export to have code run in the DLL.

The DLL registers itself with the core.

The other hack for _rt_init in seg XI works for C code.
Post by Jiri Malak
Jiri
Post by J
Post by J
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as
error if generate import library.
If you want export some symbol from DLL you must specify it, either
to compiler by __declspec(dllexport) or to linker by export
directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
(Sorry I mean data, not code, it's just struct rt_init 's)
Post by J
....
#define PRIORITY_PRELOAD(name,priority) static void
pastejunk(schedule_,name)(void); static void CPROC name(void); \
static struct rt_init __based(__segname("XI"))
pastejunk(name,_ctor_label)={0,(DEADSTART_PRELOAD_PRIORITY-1),pastejunk
(schedule_,name)};
Post by J
Post by J
\
static void pastejunk(schedule_,name)(void) { \
RegisterPriorityStartupProc(
name,TOSTR(name),priority,&pastejunk
(name,_ctor_label),WIDE__FILE__,__LINE__
Post by J
Post by J
);\
} \
void name(void)
PRIORITY_PRELOAD( InitMyCode )
{
/* do startup init here */
}
But all of these are just functions, they are not DLL exports...
Post by J
Why?
If I have static classes declared, they should still get initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
On Fri, 21 Feb 2014 10:15:32 -0800, Jiri Malak
I see; I haven't tracked this down I think.... It's part of the
automatic build system (CMake) really, but I ran into it before then
also... It runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c wcc386 -bd -br dll.c wlink system
nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c Open Watcom C x86
32-bit Optimizing Compiler Version 2.0 beta Feb 19 2014 22:40:42
(32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
loading object files searching libraries creating a Windows NT
dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module Error! No
exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a
bad status Error(E02): Make execution terminated Error(E42): Last
command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir
\all)
Post by J
Post by J
Post by J
Post by Jiri Malak
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated Error(E42): Last command
making (all) returned a bad status Error(E02): Make execution
terminated
I've been adding #if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-02-26 11:05:16 UTC
Permalink
Raw Message
Post by J
Post by Jiri Malak
I understand what you are trying to do, even if it is horible.
The problem is with incorrect use of OW tools.
Explain me why you are creating import library for DLL without any entry
point? What sense it has?
OW reports error correctly. Do you think it is a bug?
Why? Because CMake is not happy?
Solution is simple don't try to create import library for this kind of DLL
(without any entry point) because it has no sense.
--- other valid code for DLLL ---
void InitFunc()
{}
class init_me {
init_me() {
__declspec(dllimport) RegisterMyInit( void(*)(void));
RegisterMyInit( InitFunc );
}
} runme ;
----------------------------------------
// something like this in the core DLL...
LoadLibarary( "Dll.dll" );
/*class initializes*/
for( func = init_funcs; func; func = func->next )
func->init(); /* run InitFunc which was registered */
--------------------------------------
Again I don't need a dll export to have code run in the DLL.
The DLL registers itself with the core.
The other hack for _rt_init in seg XI works for C code.
Loading CLI/CLR compiled code requires running a procedure in the library
before static classses are initialzied; but that's .NET and irrelavent.
In C++ loading a DLL intializes static classes.

(Even if I had to carry a custom .cpp if you ever remove the .rtinit
functionality it's still doable, but would still run into the same issue)

I just don't know ahead of time whether a DLL to build will ahve symbols
or not... I could hack a custom build rule that doesn't call wlib...

But that's more work than demoting 'error' to 'warning' .. yes; I know it
doesn't have entry points, and it would appear to be useless, but it's
not, and hasn't been; for years. THis way I do not require ANY special
entry point in the loaded DLL.
Post by J
Post by Jiri Malak
Jiri
Post by J
Post by J
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as
error if generate import library.
If you want export some symbol from DLL you must specify it, either
to compiler by __declspec(dllexport) or to linker by export
directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
(Sorry I mean data, not code, it's just struct rt_init 's)
Post by J
....
#define PRIORITY_PRELOAD(name,priority) static void
pastejunk(schedule_,name)(void); static void CPROC name(void); \
static struct rt_init __based(__segname("XI"))
pastejunk(name,_ctor_label)={0,(DEADSTART_PRELOAD_PRIORITY-1),pastejunk
(schedule_,name)};
Post by J
Post by J
\
static void pastejunk(schedule_,name)(void) { \
RegisterPriorityStartupProc(
name,TOSTR(name),priority,&pastejunk
(name,_ctor_label),WIDE__FILE__,__LINE__
Post by J
Post by J
);\
} \
void name(void)
PRIORITY_PRELOAD( InitMyCode )
{
/* do startup init here */
}
But all of these are just functions, they are not DLL exports...
Post by J
Why?
If I have static classes declared, they should still get initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
On Fri, 21 Feb 2014 10:15:32 -0800, Jiri Malak
I see; I haven't tracked this down I think.... It's part of the
automatic build system (CMake) really, but I ran into it before then
also... It runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c wcc386 -bd -br dll.c wlink system
nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c Open Watcom C x86
32-bit Optimizing Compiler Version 2.0 beta Feb 19 2014 22:40:42
(32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
loading object files searching libraries creating a Windows NT
dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module Error! No
exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a
bad status Error(E02): Make execution terminated Error(E42): Last
command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir
\all)
Post by J
Post by J
Post by J
Post by Jiri Malak
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated Error(E42): Last command
making (all) returned a bad status Error(E02): Make execution
terminated
I've been adding #if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-02-26 12:09:55 UTC
Permalink
Raw Message
Post by J
Post by J
Post by Jiri Malak
I understand what you are trying to do, even if it is horible.
The problem is with incorrect use of OW tools.
Explain me why you are creating import library for DLL without any entry
point? What sense it has?
OW reports error correctly. Do you think it is a bug?
Why? Because CMake is not happy?
Solution is simple don't try to create import library for this kind of DLL
(without any entry point) because it has no sense.
--- other valid code for DLLL ---
void InitFunc()
{}
class init_me {
init_me() {
__declspec(dllimport) RegisterMyInit( void(*)(void));
RegisterMyInit( InitFunc );
}
} runme ;
----------------------------------------
// something like this in the core DLL...
LoadLibarary( "Dll.dll" );
/*class initializes*/
for( func = init_funcs; func; func = func->next )
func->init(); /* run InitFunc which was registered */
--------------------------------------
Again I don't need a dll export to have code run in the DLL.
The DLL registers itself with the core.
The other hack for _rt_init in seg XI works for C code.
Loading CLI/CLR compiled code requires running a procedure in the
library before static classses are initialzied; but that's .NET and
irrelavent. In C++ loading a DLL intializes static classes.
(Even if I had to carry a custom .cpp if you ever remove the .rtinit
functionality it's still doable, but would still run into the same issue)
I just don't know ahead of time whether a DLL to build will ahve symbols
or not... I could hack a custom build rule that doesn't call wlib...
But that's more work than demoting 'error' to 'warning' .. yes; I know
it doesn't have entry points, and it would appear to be useless, but
it's not, and hasn't been; for years. THis way I do not require ANY
special entry point in the loaded DLL.
did I mention that wlib leaves a .lib file so all I really have to do is
run wmake again, and the .dll and .lib are already up to date, so i get
one more project built.
Post by J
Post by J
Post by Jiri Malak
Jiri
Post by J
Post by J
On Sat, 22 Feb 2014 08:03:39 -0800, Jiri Malak
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as
error if generate import library.
If you want export some symbol from DLL you must specify it, either
to compiler by __declspec(dllexport) or to linker by export
directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in
__segname("XI")
(Sorry I mean data, not code, it's just struct rt_init 's)
Post by J
....
#define PRIORITY_PRELOAD(name,priority) static void
pastejunk(schedule_,name)(void); static void CPROC name(void); \
static struct rt_init __based(__segname("XI"))
pastejunk(name,_ctor_label)={0,(DEADSTART_PRELOAD_PRIORITY-1),pastejunk
(schedule_,name)};
Post by J
Post by J
\
static void pastejunk(schedule_,name)(void) { \
RegisterPriorityStartupProc(
name,TOSTR(name),priority,&pastejunk
(name,_ctor_label),WIDE__FILE__,__LINE__
Post by J
Post by J
);\
} \
void name(void)
PRIORITY_PRELOAD( InitMyCode )
{
/* do startup init here */
}
But all of these are just functions, they are not DLL exports...
Why?
If I have static classes declared, they should still get
initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
On Fri, 21 Feb 2014 10:15:32 -0800, Jiri Malak
I see; I haven't tracked this down I think.... It's part of the
automatic build system (CMake) really, but I ran into it before then
also... It runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c wcc386 -bd -br dll.c wlink system
nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c Open Watcom C x86
32-bit Optimizing Compiler Version 2.0 beta Feb 19 2014 22:40:42
(32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
loading object files searching libraries creating a Windows NT
dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module Error! No
exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a
bad status Error(E02): Make execution terminated Error(E42): Last
command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir
\all)
Post by J
Post by J
Post by Jiri Malak
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated Error(E42): Last command
making (all) returned a bad status Error(E02): Make execution
terminated
I've been adding #if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Jiri Malak
2014-02-26 16:31:50 UTC
Permalink
Raw Message
Sorry, you don't read what I wrote you before.
Argument that other tool chains don't report problem is irelevant.
You have not problem with wlink, DLL is created without problem.
Your problem is that you call absurdly wlib to create the import library
that is useless.

!!!! Simply remove call of wlib for your DLL and all will be OK !!!

I don't say you need some entry point in any DLL, I only explain what was
reported.
If you don't have any entry point in DLL, you must load it dynamicaly in
your application as you do.
In this case it is your bussines to handle this type of DLL's.
If you don't use DLL startup code then you are also responsible for correct
initialization OW C/C++ run-time environment.

But don't say that OW is bugy, it is not true.
You use OW tools incorrect way, it is your mistake.

Jiri
Post by J
Post by Jiri Malak
I understand what you are trying to do, even if it is horible.
The problem is with incorrect use of OW tools.
Explain me why you are creating import library for DLL without any entry
point? What sense it has?
OW reports error correctly. Do you think it is a bug?
Why? Because CMake is not happy?
Solution is simple don't try to create import library for this kind of DLL
(without any entry point) because it has no sense.
--- other valid code for DLLL ---
void InitFunc()
{}
class init_me {
init_me() {
__declspec(dllimport) RegisterMyInit( void(*)(void));
RegisterMyInit( InitFunc );
}
} runme ;
----------------------------------------
// something like this in the core DLL...
LoadLibarary( "Dll.dll" );
/*class initializes*/
for( func = init_funcs; func; func = func->next )
func->init(); /* run InitFunc which was registered */
--------------------------------------
Again I don't need a dll export to have code run in the DLL.
The DLL registers itself with the core.
The other hack for _rt_init in seg XI works for C code.
Post by Jiri Malak
Jiri
Post by J
Post by J
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as
error if generate import library.
If you want export some symbol from DLL you must specify it, either
to compiler by __declspec(dllexport) or to linker by export
directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
(Sorry I mean data, not code, it's just struct rt_init 's)
Post by J
....
#define PRIORITY_PRELOAD(name,priority) static void
pastejunk(schedule_,name)(void); static void CPROC name(void); \
static struct rt_init __based(__segname("XI"))
pastejunk(name,_ctor_label)={0,(DEADSTART_PRELOAD_PRIORITY-1),pastejunk
(schedule_,name)};
Post by J
Post by J
\
static void pastejunk(schedule_,name)(void) { \
RegisterPriorityStartupProc(
name,TOSTR(name),priority,&pastejunk
(name,_ctor_label),WIDE__FILE__,__LINE__
Post by J
Post by J
);\
} \
void name(void)
PRIORITY_PRELOAD( InitMyCode )
{
/* do startup init here */
}
But all of these are just functions, they are not DLL exports...
Post by J
Why?
If I have static classes declared, they should still get initialized;
which can then call into other libraries to register its entry points.
Post by Jiri Malak
Jiri
Post by J
On Fri, 21 Feb 2014 10:15:32 -0800, Jiri Malak
I see; I haven't tracked this down I think.... It's part of the
automatic build system (CMake) really, but I ran into it before then
also... It runs something like this...
--- test.bat ---
echo void f( void ){ } > dll.c wcc386 -bd -br dll.c wlink system
nt_dll file { dll.obj }
wlib -c -q -n -b dll.lib +'dll.dll'
--- end test.bat ---
(create a file, dll.c, with a function in it)
compile the source link the source
use wlib to build the symbol table
wlib generates a error state, and stops build.
"Error! No exports in 'dll.dll'"
------------- Test Output ------------
M:\tmp\watcom\test_nosyms>mk.bat
M:\tmp\watcom\test_nosyms>echo void f( void ){ } 1>dll.c
M:\tmp\watcom\test_nosyms>wcc386 -bd -br dll.c Open Watcom C x86
32-bit Optimizing Compiler Version 2.0 beta Feb 19 2014 22:40:42
(32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
dll.c: 1 lines, included 35, 0 warnings, 0 errors Code size: 11
M:\tmp\watcom\test_nosyms>wlink system nt_dll file { dll.obj }
Open Watcom Linker Version 2.0 beta Feb 19 2014 22:23:37 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public
License. See http://www.openwatcom.org/ for details.
loading object files searching libraries creating a Windows NT
dynamic link library
M:\tmp\watcom\test_nosyms>wlib -c -q -n -b dll.lib +'dll.dll'
Error! No exports in 'dll.dll'
M:\tmp\watcom\test_nosyms>
Post by Jiri Malak
If you give me more details or reference to OW bugzilla I can fix it.
Jiri
Post by J
making a shared library without entry points also still fails.....
Linking C shared library application_delay.module Error! No
exports in 'application_delay.module'
Error(E42): Last command making
(src\utils\application_delay\application_delay.module) returned a
bad status Error(E02): Make execution terminated Error(E42): Last
command making
(src\utils\application_delay\CMakeFiles\application_delay.module.dir
\all)
Post by J
Post by J
Post by J
Post by Jiri Malak
Post by J
Post by Jiri Malak
Post by J
returned a bad
status
Error(E02): Make execution terminated Error(E42): Last command
making (all) returned a bad status Error(E02): Make execution
terminated
I've been adding #if __WATCOMC__ < (next version)
PUBLIC( void, ExportThis )( void )
{
}
#endif
Someday this will be fixed :) (thought 1.9 actually had that fixed)
J
2014-02-27 02:33:50 UTC
Permalink
Raw Message
Post by Jiri Malak
You have not problem with wlink, DLL is created without problem.
Your problem is that you call absurdly wlib to create the import library
that is useless.
I don't know ahead of time whether a project will need wlib or not.
I think in my prior build system, I put the rules to build the lib as part
of the dll... so did an extra
then emit nothing, and don't fail.
Post by Jiri Malak
But don't say that OW is bugy, it is not true.
You use OW tools incorrect way, it is your mistake.
incorrect is an opinion...
Post by Jiri Malak
Jiri
Interesting...

(no previous test.lib in the directory)

-----------------------------------
M:\tmp\watcom>wlib test.lib
Open Watcom Library Manager Version 2.0 beta Feb 19 2014 22:22:23 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Warning! Cannot open 'test.lib' - library will be created
Warning! Library contains no external symbols


M:\tmp\watcom>ls
test.lib

M:\tmp\watcom>

---------------------------------

that's not an error....
and it results in a .lib ... which is what made my make-based system not
have an issue... because I would do a wlib to 'touch' the library and then
wlib <dll> to append dll exports to it (and ignore failure)
Jiri Malak
2014-02-27 07:03:59 UTC
Permalink
Raw Message
You call wlib as extra step after creating DLL for any type of DLL (with
and without entry points), even if for DLL without entry points it is
incorrect step.

Generaly correct is to use wlink option "op implib" for creating import
libraries during linking process instead of extra wlib call then no
similar problem occure, because wlink automaticaly suppress creating
import library for DLL without any entry point.

Wlib shoud be used for creating import libraries from DLL with entry
points only if you have no source code and you can not create this DLL.

Jiri
Post by J
Post by Jiri Malak
You have not problem with wlink, DLL is created without problem.
Your problem is that you call absurdly wlib to create the import
library that is useless.
I don't know ahead of time whether a project will need wlib or not.
I think in my prior build system, I put the rules to build the lib as
part of the dll... so did an extra then emit nothing, and don't fail.
Post by Jiri Malak
But don't say that OW is bugy, it is not true.
You use OW tools incorrect way, it is your mistake.
incorrect is an opinion...
Post by Jiri Malak
Jiri
Interesting...
(no previous test.lib in the directory)
-----------------------------------
M:\tmp\watcom>wlib test.lib Open Watcom Library Manager Version 2.0 beta
Feb 19 2014 22:22:23 (32-bit)
Copyright (c) 2002-2014 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Warning! Cannot open 'test.lib' - library will be created Warning!
Library contains no external symbols
M:\tmp\watcom>ls test.lib
M:\tmp\watcom>
---------------------------------
that's not an error....
and it results in a .lib ... which is what made my make-based system not
have an issue... because I would do a wlib to 'touch' the library and
then wlib <dll> to append dll exports to it (and ignore failure)
J
2014-02-27 20:44:16 UTC
Permalink
Raw Message
Post by Jiri Malak
You call wlib as extra step after creating DLL for any type of DLL (with
and without entry points), even if for DLL without entry points it is
incorrect step.
Generaly correct is to use wlink option "op implib" for creating import
libraries during linking process instead of extra wlib call then no
similar problem occure, because wlink automaticaly suppress creating
import library for DLL without any entry point.
Wlib shoud be used for creating import libraries from DLL with entry
points only if you have no source code and you can not create this DLL.
Jiri
Now that is some useful advice :) thanx, I forwarded a patch for cmake.
Paul S. Person
2014-02-25 17:57:23 UTC
Permalink
Raw Message
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as error if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
<snip code defining>
Post by J
PRIORITY_PRELOAD( InitMyCode )
but no LibMain() (and, no, "InitMyCode" is not renamed to "LibMain" by
the PRIORITY_PRELOAD macro).

Have you tried inserting the required function

BOOL APIENTRY LibMain( HANDLE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved )
(with an implementation that at least returns a BOOL) into the DLL?

See the Programmer's Guide Help "NT: Creating a Sample Dynamic Link
Library". Not working with NT? Find the equivalent page in the
Programmer's guide for whatever you /are/ using.

The result is clear: you cannot have a data-only DLL: it must contain
a LibMain() implementation. But that is not to say that LibMain() has
to do anything (except return a BOOL), or that the rest of the DLL
cannot be purely data.

Note: Some compilers create (or have in the past created) one
automatically if none is present, fostering the illusion that a
data-only DLL is possible. Open Watcom is not one of them.

Note: Technically, every DLL is supposed to have a termination
function, but the vast majority, if not all, of compilers create that
automatically. DLLs were originally intended to work in 16-bit
non-enhanced Windows environments, and both LibMain() and the
termination function had things that had to be done in that context,
IIRC.
--
"Nature must be explained in
her own terms through
the experience of our senses."
J
2014-02-26 10:51:11 UTC
Permalink
Raw Message
On Tue, 25 Feb 2014 09:57:23 -0800, Paul S. Person
Post by Paul S. Person
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as error if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
<snip code defining>
Post by J
PRIORITY_PRELOAD( InitMyCode )
but no LibMain() (and, no, "InitMyCode" is not renamed to "LibMain" by
the PRIORITY_PRELOAD macro).
Have you tried inserting the required function
BOOL APIENTRY LibMain( HANDLE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved )
(with an implementation that at least returns a BOOL) into the DLL?
See the Programmer's Guide Help "NT: Creating a Sample Dynamic Link
Library". Not working with NT? Find the equivalent page in the
Programmer's guide for whatever you /are/ using.
The result is clear: you cannot have a data-only DLL: it must contain
a LibMain() implementation. But that is not to say that LibMain() has
to do anything (except return a BOOL), or that the rest of the DLL
cannot be purely data.
Note: Some compilers create (or have in the past created) one
automatically if none is present, fostering the illusion that a
data-only DLL is possible. Open Watcom is not one of them.
Note: Technically, every DLL is supposed to have a termination
function, but the vast majority, if not all, of compilers create that
automatically. DLLs were originally intended to work in 16-bit
non-enhanced Windows environments, and both LibMain() and the
termination function had things that had to be done in that context,
IIRC.
Really the issue is Open Watcom is the ONLY compiler that has an issue
with this.
GCC generates DLLs with no exports just fine
msvc also
In face watcom has no issue there except when the wlib tries to process
the empty DLL
Which works just fine. And I have no issue with any usage.

This works under for a C++ example too that doesn't exploit compiler
specifics

(I have to use a segment in msvc)
(gcc provides a __attribute((constructor)) which sort of works, but has no
priority itself)

There is no problem running code at this point, as long as you repsect all
rules of DllMain or LibMain. Do not create a thread... etc. But I don't,
I just add the real entry point into a list, so right at the beginning I
can call the properly scheduled inits that came in dynamially
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-02-26 12:02:38 UTC
Permalink
Raw Message
Post by J
On Tue, 25 Feb 2014 09:57:23 -0800, Paul S. Person
Post by Paul S. Person
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as
error
if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
<snip code defining>
Post by J
PRIORITY_PRELOAD( InitMyCode )
but no LibMain() (and, no, "InitMyCode" is not renamed to "LibMain" by
the PRIORITY_PRELOAD macro).
Have you tried inserting the required function
BOOL APIENTRY LibMain( HANDLE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved )
(with an implementation that at least returns a BOOL) into the DLL?
See the Programmer's Guide Help "NT: Creating a Sample Dynamic Link
Library". Not working with NT? Find the equivalent page in the
Programmer's guide for whatever you /are/ using.
The result is clear: you cannot have a data-only DLL: it must contain
a LibMain() implementation. But that is not to say that LibMain() has
to do anything (except return a BOOL), or that the rest of the DLL
cannot be purely data.
Note: Some compilers create (or have in the past created) one
automatically if none is present, fostering the illusion that a
data-only DLL is possible. Open Watcom is not one of them.
Note: Technically, every DLL is supposed to have a termination
function, but the vast majority, if not all, of compilers create that
automatically. DLLs were originally intended to work in 16-bit
non-enhanced Windows environments, and both LibMain() and the
termination function had things that had to be done in that context,
IIRC.
I'm I didn't actually read the fullness of your message.
LoadLibrary provides a single entry point in a single source file; and I
then have to know I already have one and track that down.

I can add modules that register additional functionality by adding a .c
file to compile. no compile flags, no other lists to be modified. no
libmain to track down or create.

And libmain still has the issue that you can't do fancy things like
CreateThread().
Post by J
Really the issue is Open Watcom is the ONLY compiler that has an issue
with this.
GCC generates DLLs with no exports just fine
msvc also
In face watcom has no issue there except when the wlib tries to process
the empty DLL
Which works just fine. And I have no issue with any usage.
This works under for a C++ example too that doesn't exploit compiler
specifics
(I have to use a segment in msvc)
(gcc provides a __attribute((constructor)) which sort of works, but has
no priority itself)
There is no problem running code at this point, as long as you repsect
all rules of DllMain or LibMain. Do not create a thread... etc. But I
don't, I just add the real entry point into a list, so right at the
beginning I can call the properly scheduled inits that came in dynamially
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-02-26 12:05:11 UTC
Permalink
Raw Message
Post by J
Post by J
On Tue, 25 Feb 2014 09:57:23 -0800, Paul S. Person
Post by Paul S. Person
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as
error
if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
<snip code defining>
Post by J
PRIORITY_PRELOAD( InitMyCode )
but no LibMain() (and, no, "InitMyCode" is not renamed to "LibMain" by
the PRIORITY_PRELOAD macro).
Have you tried inserting the required function
BOOL APIENTRY LibMain( HANDLE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved )
(with an implementation that at least returns a BOOL) into the DLL?
See the Programmer's Guide Help "NT: Creating a Sample Dynamic Link
Library". Not working with NT? Find the equivalent page in the
Programmer's guide for whatever you /are/ using.
The result is clear: you cannot have a data-only DLL: it must contain
a LibMain() implementation. But that is not to say that LibMain() has
to do anything (except return a BOOL), or that the rest of the DLL
cannot be purely data.
Note: Some compilers create (or have in the past created) one
automatically if none is present, fostering the illusion that a
data-only DLL is possible. Open Watcom is not one of them.
Note: Technically, every DLL is supposed to have a termination
function, but the vast majority, if not all, of compilers create that
automatically. DLLs were originally intended to work in 16-bit
non-enhanced Windows environments, and both LibMain() and the
termination function had things that had to be done in that context,
IIRC.
I'm I didn't actually read the fullness of your message.
LoadLibrary provides a single entry point in a single source file; and I
then have to know I already have one and track that down.
I can add modules that register additional functionality by adding a .c
file to compile. no compile flags, no other lists to be modified. no
libmain to track down or create.
And libmain still has the issue that you can't do fancy things like
CreateThread().
And then I reread it; so you're telling me that since 2006 none of my code
has worked without entry points on other systems? It would under watcom
if I just bypass the wlib rule to make a link library with 0 symbols. I
just have to make a

#define PUBLIC(init_name) static __declspec(dllexport) void
init_name##__LINE__( void )

#ifdef __WATCOMC__
PUBLIC( EntryPoint)
{
}
#endif

... it's a watcom only exception.

and I never use it; and it's not called DllMain or LibMain.
Post by J
Post by J
Really the issue is Open Watcom is the ONLY compiler that has an issue
with this.
GCC generates DLLs with no exports just fine
msvc also
In face watcom has no issue there except when the wlib tries to process
the empty DLL
Which works just fine. And I have no issue with any usage.
This works under for a C++ example too that doesn't exploit compiler
specifics
(I have to use a segment in msvc)
(gcc provides a __attribute((constructor)) which sort of works, but has
no priority itself)
There is no problem running code at this point, as long as you repsect
all rules of DllMain or LibMain. Do not create a thread... etc. But I
don't, I just add the real entry point into a list, so right at the
beginning I can call the properly scheduled inits that came in dynamially
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Paul S. Person
2014-02-26 17:23:06 UTC
Permalink
Raw Message
Post by J
Post by J
And libmain still has the issue that you can't do fancy things like
CreateThread().
And your point is?

Originally, IIRC, LibMain() was required to release any bound data
segment, a "feature" of the Win16 non-enhanced Windows.
Post by J
And then I reread it; so you're telling me that since 2006 none of my code
has worked without entry points on other systems?
Post by J
Post by Paul S. Person
Note: Some compilers create (or have in the past created) one
automatically if none is present, fostering the illusion that a
data-only DLL is possible. Open Watcom is not one of them.
Not having to provide it yourself doesn't mean it isn't there!
Post by J
It would under watcom
if I just bypass the wlib rule to make a link library with 0 symbols. I
just have to make a
#define PUBLIC(init_name) static __declspec(dllexport) void
init_name##__LINE__( void )
#ifdef __WATCOMC__
PUBLIC( EntryPoint)
{
}
#endif
... it's a watcom only exception.
Except, of course, that you still aren't using "LibMain" as the name
of the function.
Post by J
and I never use it; and it's not called DllMain or LibMain.
Which means we may be talking about two different things: something
the OW runtime needs, or doesn't need, and something Windows needs.

Reading some of the other posts, however, it is certainly possible
that this is not the explanation and that you need to pursue other
paths. Indeed, it is possible (since this issue has come up before)
that OW /does/ provide a null LibMain() for you and that everything I
said is irrelevant. My post is based on my memories of my experience
with DLLs ... which is at least 15 years old at this point. I should
probably just forget it entirely, and avoid these messes.

Calming down might be a good idea as well. Posting three identical
replies is a software problem with whatever newsreader you are
reading; posting three different replies suggests a tendency to react
immediately rather than to comprehend before responding.
--
"Nature must be explained in
her own terms through
the experience of our senses."
J
2014-02-27 02:41:16 UTC
Permalink
Raw Message
On Wed, 26 Feb 2014 09:23:06 -0800, Paul S. Person
Post by Paul S. Person
Post by J
Post by Paul S. Person
Note: Some compilers create (or have in the past created) one
automatically if none is present, fostering the illusion that a
data-only DLL is possible. Open Watcom is not one of them.
Not having to provide it yourself doesn't mean it isn't there!
Post by J
It would under watcom
if I just bypass the wlib rule to make a link library with 0 symbols. I
just have to make a
#define PUBLIC(init_name) static __declspec(dllexport) void
init_name##__LINE__( void )
#ifdef __WATCOMC__
PUBLIC( EntryPoint)
{
}
#endif
... it's a watcom only exception.
Except, of course, that you still aren't using "LibMain" as the name
of the function.
Post by J
and I never use it; and it's not called DllMain or LibMain.
Which means we may be talking about two different things: something
the OW runtime needs, or doesn't need, and something Windows needs.
Reading some of the other posts, however, it is certainly possible
that this is not the explanation and that you need to pursue other
paths. Indeed, it is possible (since this issue has come up before)
that OW /does/ provide a null LibMain() for you and that everything I
said is irrelevant. My post is based on my memories of my experience
with DLLs ... which is at least 15 years old at this point. I should
probably just forget it entirely, and avoid these messes.
Calming down might be a good idea as well. Posting three identical
replies is a software problem with whatever newsreader you are
reading; posting three different replies suggests a tendency to react
immediately rather than to comprehend before responding.
But whether or not I implemented dllmain or libmain is not the issue that
openwatcom does silly things that make extra work; and it's probably a 1
line change that is being resisted... on no merit other than...


"In C You do rude things, therefore I dismiss you"
"in c++ ... well it doesn't matter; you're dismissed"

And, I recently learned that when wlib says 'not writing a library' it
actually does.

Libmain is not required under windows; there is in the PE header 'entry
point'... which is library deadstart code that is a stub of openwatcom
runtime library at this point; which tries to link somehow optionally
against my dllmain/libmain or its own internally (which it actually
doesn't have, and disassembling the object reveals there is no required
special thing)

LibMain in 16 bit systems is something about unlocking heap... but that
was like
10 years ago that it was retired;
and more years ago that it wasn't required to support for new developments.
64 bit systems now omit syswow16 support...
Jiri Malak
2014-02-27 07:33:17 UTC
Permalink
Raw Message
Post by J
And, I recently learned that when wlib says 'not writing a library' it
actually does.
You try again search something magic in Open Watcom, because you are
working by method trial-error instead of reading wlib documentation to
better understand what you are doing and how you can control wlib.

Don't expect any help if you will continue discussion this way.

Anyway this discussion is now a little out-of-scope.

Jiri
Marty Stanquist
2014-02-27 20:05:43 UTC
Permalink
Raw Message
Post by J
And, I recently learned that when wlib says 'not writing a library' it
actually does.
You try again search something magic in Open Watcom, because you are
working by method trial-error instead of reading wlib documentation to
better understand what you are doing and how you can control wlib.

Don't expect any help if you will continue discussion this way.

Anyway this discussion is now a little out-of-scope.

Jiri

I hope the following application note will add clarification. This does not
seem to be a tools issue.

HOWTO: How To Export Data from a DLL or an Application
http://support.microsoft.com/kb/90530

Marty
J
2014-02-27 20:47:08 UTC
Permalink
Raw Message
Post by Marty Stanquist
HOWTO: How To Export Data from a DLL or an Application
http://support.microsoft.com/kb/90530
Marty
Exported data always fails.

I did notice that watcom did fix its function pointer import error... I
had to previously add an extra layer of indirection on imported pointer
from other DLLs; didn't fail if it was in the same DLL.

But it's been my experience that exporting data is unreliable between
compiler platforms.
J
2014-02-27 20:48:12 UTC
Permalink
Raw Message
Post by Jiri Malak
Post by J
And, I recently learned that when wlib says 'not writing a library' it
actually does.
You try again search something magic in Open Watcom, because you are
working by method trial-error instead of reading wlib documentation to
better understand what you are doing and how you can control wlib.
I did read it years ago, and for various reasons settled on doing it that
way, which works except for this edge case.
Post by Jiri Malak
Jiri
actually it was misreading the warning...
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
E. S. Fabian
2014-02-27 13:38:20 UTC
Permalink
Raw Message
Dear Sir:

* One of the main purposes for the Open Watcom development system is its
ability to produce portable code, including for LEGACY systems, such as
PC-DOS.
* You forget that there is no STANDARD for any styyle of shared libraries,
dynamic link libraries included. For their implementation Microsoft reserves
the right to change syntax and content, often to be found only be deep down
search. Backward compatiblity is virtually discouraged.
* You have permission to submit changes to the wlib code which overcomes
your perceived shortcoming, instead of vociferously and voluminously
complaining. My guess is that doing so would have taken considerably less
time than all your posts on this topic. If other users find the change
useful, it will undoubtedly be welcomed. Remember also that there is the
official OW system, which is under Marty Standquist's control, and the fork
maintained by Jiri Malak, which contains many additional enhancements, and
under his sole control.
--
Steve
Marty Stanquist
2014-02-27 20:08:33 UTC
Permalink
Raw Message
"E. S. Fabian" wrote in message news:lenf4s$18c$***@www.openwatcom.org...

Dear Sir:

* One of the main purposes for the Open Watcom development system is its
ability to produce portable code, including for LEGACY systems, such as
PC-DOS.
* You forget that there is no STANDARD for any styyle of shared libraries,
dynamic link libraries included. For their implementation Microsoft reserves
the right to change syntax and content, often to be found only be deep down
search. Backward compatiblity is virtually discouraged.
* You have permission to submit changes to the wlib code which overcomes
your perceived shortcoming, instead of vociferously and voluminously
complaining. My guess is that doing so would have taken considerably less
time than all your posts on this topic. If other users find the change
useful, it will undoubtedly be welcomed. Remember also that there is the
official OW system, which is under Marty Stanquist's control, and the fork
maintained by Jiri Malak, which contains many additional enhancements, and
under his sole control.
--
Steve

<duplicate post>

I hope the following application note will add clarification. This does not
seem to be a tools issue.

HOWTO: How To Export Data from a DLL or an Application
http://support.microsoft.com/kb/90530

Marty
J
2014-02-27 20:49:49 UTC
Permalink
Raw Message
Post by E. S. Fabian
* One of the main purposes for the Open Watcom development system is its
ability to produce portable code, including for LEGACY systems, such as
PC-DOS.
* You forget that there is no STANDARD for any styyle of shared libraries,
dynamic link libraries included. For their implementation Microsoft reserves
the right to change syntax and content, often to be found only be deep down
search. Backward compatiblity is virtually discouraged.
* You have permission to submit changes to the wlib code which overcomes
your perceived shortcoming, instead of vociferously and voluminously
complaining. My guess is that doing so would have taken considerably less
time than all your posts on this topic. If other users find the change
useful, it will undoubtedly be welcomed. Remember also that there is the
official OW system, which is under Marty Standquist's control, and the fork
maintained by Jiri Malak, which contains many additional enhancements, and
under his sole control.
It's 5 years of built of frustration with the issue. So now I spend a
week making it known in all of its permutations. I'm done, I got what I
need.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Paul S. Person
2014-02-28 18:17:29 UTC
Permalink
Raw Message
Post by J
It's 5 years of built of frustration with the issue. So now I spend a
week making it known in all of its permutations. I'm done, I got what I
need.
As Jiri points out in a separate thread, this is not really the best
newsgroup for this sort of discussion.

The better place is

openwatcom.users.c_cpp

which is intended to help users figure out how to use OW.

In my personal experience, when I have a programming problem, the
problem is almost always my fault, not the fault of OW or any of its
tools. I am not saying that OW is bug-free, but the chances of running
into one of them is not very great.

The point is that, like Jiri, I would suggest a different approach to
your reports: not "OW won't do this" but "how do I do this with OW?"
or "this doesn't seem to work in OW; what am I doing wrong?".

And then post to openwatcom.users.c_cpp and, hopefully, get a
response.
--
"Nature must be explained in
her own terms through
the experience of our senses."
J
2014-03-11 06:49:42 UTC
Permalink
Raw Message
Post by Paul S. Person
As Jiri points out in a separate thread, this is not really the best
newsgroup for this sort of discussion.
The better place is
openwatcom.users.c_cpp
which is intended to help users figure out how to use OW.
In my personal experience, when I have a programming problem, the
problem is almost always my fault, not the fault of OW or any of its
tools. I am not saying that OW is bug-free, but the chances of running
into one of them is not very great.
The point is that, like Jiri, I would suggest a different approach to
your reports: not "OW won't do this" but "how do I do this with OW?"
or "this doesn't seem to work in OW; what am I doing wrong?".
And then post to openwatcom.users.c_cpp and, hopefully, get a
response.
I've been a user and contributor since openwatcom 14... clbr14 was
probably the oldest I had.... It's not a matter of not knowing the tools;
although having been developing for 24 years, maybe a few things slip
through that were not of the utmost import at the time. If it was a user
issue I'd have posted there.

*whatever I shouldn't have said anything*
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Paul S. Person
2014-03-11 16:12:51 UTC
Permalink
Raw Message
Post by J
Post by Paul S. Person
As Jiri points out in a separate thread, this is not really the best
newsgroup for this sort of discussion.
The better place is
openwatcom.users.c_cpp
which is intended to help users figure out how to use OW.
In my personal experience, when I have a programming problem, the
problem is almost always my fault, not the fault of OW or any of its
tools. I am not saying that OW is bug-free, but the chances of running
into one of them is not very great.
The point is that, like Jiri, I would suggest a different approach to
your reports: not "OW won't do this" but "how do I do this with OW?"
or "this doesn't seem to work in OW; what am I doing wrong?".
And then post to openwatcom.users.c_cpp and, hopefully, get a
response.
I've been a user and contributor since openwatcom 14... clbr14 was
probably the oldest I had.... It's not a matter of not knowing the tools;
although having been developing for 24 years, maybe a few things slip
through that were not of the utmost import at the time. If it was a user
issue I'd have posted there.
It /is/ a user issue -- the DLL issue is about the user using the
tools incorrectly, as Jiri clearly showed.

And your latest post, on different struct sizes in C and C++ is also a
user issue. The question is, "why are they different" (if the
difference is actually important to you) or "why does this compiled
code crash" (if not). None of which is a compiler problem.

If it is the /compiler itself/ that is crashing, that might be worth
looking at here, but you would need to pin down what it is in /your
code/ that provokes the crash. You would, need, in other words, a
/simple test case/ that /crashes the compiler/ when /one
single-statement line/ is not commented out or otherwise clearly
skipped, and which compiles cleanly when it is commented out or
otherwise clearly skipped. If you can't do that, then you simply
haven't diagnosed the problem yet.
--
"Nature must be explained in
her own terms through
the experience of our senses."
J
2014-03-11 18:47:58 UTC
Permalink
Raw Message
Post by Paul S. Person
It /is/ a user issue -- the DLL issue is about the user using the
tools incorrectly, as Jiri clearly showed.
wlib has no issue making a .lib with 0 symbols
wlink has no issue using a .lib with 0 symbols
there are lots of conditions that produce a valid library without exported
entry points; the only start point required is in the PE header of the
library.

why would in 1 particular instance be an error; a fatal error that stops
the build; or actually just introduces inconcenient hurdles that just
require remaking without doing anything (unless you want the first build
to be clean).

Seems like a poor decision in the design/implementation of the tool rather
than an error using the tool.
Post by Paul S. Person
And your latest post, on different struct sizes in C and C++ is also a
user issue. The question is, "why are they different" (if the
difference is actually important to you) or "why does this compiled
code crash" (if not). None of which is a compiler problem.
It's because of a file that was added in 2.0; it is not an issue in any
prior version. Header files are part of the core package.
Post by Paul S. Person
If it is the /compiler itself/ that is crashing, that might be worth
looking at here, but you would need to pin down what it is in /your
code/ that provokes the crash. You would, need, in other words, a
/simple test case/ that /crashes the compiler/ when /one
single-statement line/ is not commented out or otherwise clearly
skipped, and which compiles cleanly when it is commented out or
otherwise clearly skipped. If you can't do that, then you simply
haven't diagnosed the problem yet.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-03-11 19:06:00 UTC
Permalink
Raw Message
Post by J
Post by Paul S. Person
It /is/ a user issue -- the DLL issue is about the user using the
tools incorrectly, as Jiri clearly showed.
wlib has no issue making a .lib with 0 symbols
wlink has no issue using a .lib with 0 symbols
there are lots of conditions that produce a valid library without
exported entry points; the only start point required is in the PE header
of the library.
why would in 1 particular instance be an error; a fatal error that stops
the build; or actually just introduces inconcenient hurdles that just
require remaking without doing anything (unless you want the first build
to be clean).
Seems like a poor decision in the design/implementation of the tool
rather than an error using the tool.
Just because there's a workable workaround doesn't mean wlib isn't broken;
nor does it mean that using the workaround is a 'correct' way vs any other
way labeled 'incorrect'.
documentation of wlib at
http://www.openwatcom.org/ftp/manuals/current/tools.pdf

--- snip ---

4.8 Creating Import Libraries
The Open Watcom Library Manager can also be used to create import
libraries from Dynamic Link
Libraries. Import libraries are used when linking OS/2, Win16 or Win32
applications.
Example:
wlib implib +dynamic.dll
In the above example, the following actions are performed. For each
external symbol in the specified
Dynamic Link Library, a special object module is created that identifies
the external symbol and the actual
name of the Dynamic Link Library it is defined in. This object module is
then added to the specified
library. The resulting library is called an import library.


--------

The documentation says this is how to do it; it does not say 'only do this
if you don't have any other way' it says 'can be used to create import
libraries...'; which it can't.



So how am I going against the documentation; am I somehow trying to use
wlib to compile? That would be an error using the tool.
J
2014-03-11 19:13:46 UTC
Permalink
Raw Message
Post by J
--- snip ---
4.8 Creating Import Libraries
The Open Watcom Library Manager can also be used to create import
libraries from Dynamic Link
Libraries. Import libraries are used when linking OS/2, Win16 or Win32
applications.
wlib implib +dynamic.dll
In the above example, the following actions are performed. For each
external symbol in the specified
Dynamic Link Library, a special object module is created that identifies
the external symbol and the actual
name of the Dynamic Link Library it is defined in. This object module is
then added to the specified
library. The resulting library is called an import library.
--------
The documentation says this is how to do it; it does not say 'only do
this if you don't have any other way' it says 'can be used to create
import libraries...';
And; because I know that you won't fill in the information yourself; I'll
have to make a third post....

there is no mention of using wlink in this step... not as 'a preferred
way' or 'the correct way' in fact, I followed exactly what the
documentation said to do; so how am I to know that I'm in error using the
tools they way they were documented???
J
2014-03-11 20:55:50 UTC
Permalink
Raw Message
Post by Paul S. Person
If it is the /compiler itself/ that is crashing, that might be worth
looking at here, but you would need to pin down what it is in /your
code/ that provokes the crash. You would, need, in other words, a
/simple test case/ that /crashes the compiler/ when /one
single-statement line/ is not commented out or otherwise clearly
skipped, and which compiles cleanly when it is commented out or
otherwise clearly skipped. If you can't do that, then you simply
haven't diagnosed the problem yet.
It's a shame I didn't get to see this before I spent the 6 hours doing..
wmake VERBOSE=1 > zz.bat
*get first make line subst -s with VERBOSE=1*
zz.bat >yy.bat
*get first make line subst -s with VERBOSE=1*
*touch sources that are affected*
yy.bat > xx.bat
*take compile lines; add -plc, change output file to a .i*

compile the .i itself to see if it produces the same result
*success*
modify 2.4M files to remove blank lines (repeated #includes) ... to remove
comments ...

I should include the two sources I used they're small; FTE editor which
works really well *except* creating a newline starts space filled, and
while return(enter) reformats the line, moving with the arrow keys doesn't
reformat the space fill to tab-fill.;.

Modify 1.7M files to remove subsequent headers; since the code was just a
small routine, everything else was just definitions.... mostly unused;

*find deletion point that causes a match condition*

discover that there's a new file added in 2.0; I'm sorry I have to say
just once.... 'so ya, eat me very much, bye'.





--- Prequel ---

Not to mention the hour I spent trying to build a ground up example to
find the failure....

-discover compiler crash
- fix code that caused the crash
- not reported, incorrect use of tools, feeding it badly syntaxed code...
- move on...

* remember crash in some watcom tool and report it; unfortuantly vaguely.
Or maybe it deserves a placeholder topic so I can go back and report what
did cause it? *



-- postfix code to strip newlines --


#include <stdio.h>
int main( int argc, char **argv )
{
FILE *file =fopen( argv[1], "rt" );
FILE *fileout = fopen( argv[2], "wt" );
char buffer[4095];
while( fgets( buffer, 4094, file ) )
{
char *blanks = buffer;
while( blanks[0] == ' ' )
blanks++;
if( strlen( blanks ) > 1 )
fputs( buffer, fileout );
}
fclose( file );
fclose( fileout );
return 0;

}

-- postfix code to strip comments --



#include <stdio.h>


int main( int argc, char **argv )
{
FILE *file =fopen( argv[1], "rt" );
FILE *fileout = fopen( argv[2], "wt" );
char buffer[4095];
int c;
int slashes = 0;
int block = 0;
int end_slashes = 0;
while( ( c = fgetc( file ) ) >= 0 )
{
if( block )
{
switch( end_slashes )
{
case 0:
if( c == '*' )
end_slashes++;
break;
case 1:
if( c == '/' )
{
block = 0;
slashes = 0;
end_slashes = 0;
}
else if( c == '*' )
{
}
else
{
end_slashes = 0;
}
break;
}
}
else
{
switch( slashes )
{
case 0:
if( c == '/' )
slashes++;
else
fputc( c, fileout );
break;
case 1:
if( c == '/' )
slashes++;
else if( c == '*' )
block = 1;
else
{
slashes = 0;
fputc( '/', fileout );
fputc( c, fileout );
}
break;
case 2:
if( c == '\n' )
{
slashes = 0;
fputc( c, fileout );
}
break;
}
}
}
fclose( file );
fclose( fileout );
return 0;
}
Paul S. Person
2014-03-12 16:28:54 UTC
Permalink
Raw Message
On Tue, 11 Mar 2014 13:55:50 -0700, J <***@gmail.com> wrote:

First, the OW documentation is known to be written for people who
already know what they are doing and only need a reminder of the
details, and not for newbies.

This is actually fairly normal: by the time someone is qualified to
write the documentation, he or she no longer remembers what it was
like to be a newbie. Newbies, by definition, don't have the technical
knowledge to write the documentation.

IOW, you made a mistake. Get over it.

Second, the news groups on openwatcom are /not/, generally speaking,
populated by people who use Jiri's version. Well, so far as I know,
anyway.
Post by J
Post by Paul S. Person
If it is the /compiler itself/ that is crashing, that might be worth
looking at here, but you would need to pin down what it is in /your
code/ that provokes the crash. You would, need, in other words, a
/simple test case/ that /crashes the compiler/ when /one
single-statement line/ is not commented out or otherwise clearly
skipped, and which compiles cleanly when it is commented out or
otherwise clearly skipped. If you can't do that, then you simply
haven't diagnosed the problem yet.
<snip sarcasm>
Post by J
discover that there's a new file added in 2.0; I'm sorry I have to say
just once.... 'so ya, eat me very much, bye'.
2.0 is a Jiri production. OW is not, in any way, responsible for it or
it's behavior. Does he have a web site? Or a usenet newsgroup? Or (see
below) a Buzgilla?
Post by J
Not to mention the hour I spent trying to build a ground up example to
find the failure....
-discover compiler crash
- fix code that caused the crash
- not reported, incorrect use of tools, feeding it badly syntaxed code...
- move on...
* remember crash in some watcom tool and report it; unfortuantly vaguely.
Or maybe it deserves a placeholder topic so I can go back and report what
did cause it? *
That is what Bugzilla is for: you report the bug with as much detail
as possible when it crashes, and come back with a clear test case or
even the fix if no one has fixed it in the meantime.

The usenet newsgroup "openwatcom.bugzilla" is composed of summaries (I
think they are summaries) from Bugzilla, which allows anyone to see
any current activity. Responses, of course, should be on Bugzilla.
--
"Nature must be explained in
her own terms through
the experience of our senses."
J
2014-03-12 17:14:33 UTC
Permalink
Raw Message
Post by Paul S. Person
IOW, you made a mistake. Get over it.
what mistake? Attempting to improve watcom?
J
2014-03-12 18:17:26 UTC
Permalink
Raw Message
On Wed, 12 Mar 2014 09:28:54 -0700, Paul S. Person
Post by Paul S. Person
First, the OW documentation is known to be written for people who
already know what they are doing and only need a reminder of the
details, and not for newbies.
This is actually fairly normal: by the time someone is qualified to
write the documentation, he or she no longer remembers what it was
like to be a newbie. Newbies, by definition, don't have the technical
knowledge to write the documentation.
IOW, you made a mistake. Get over it.
Second, the news groups on openwatcom are /not/, generally speaking,
populated by people who use Jiri's version. Well, so far as I know,
anyway.
So... you're insistance that the error is mine leads me to beleive you
think no fault could exist in the tools that hasn't already been rooted
out; much like everything that can be invented has already been invented.
And just because people do advanced things that push edge conditions such
that 'following the documented steps is a wrong thing to do' ... and just
because it's an isolated person who has experienced this edge condition
and; again, points to an inconsisntancy between watcom and the rest of the
world...

But anyway...

So; read the documentation kid 'stop bothering me' .. well.. me and jiri.
(well I did, and that was no answer; in fact backs up that how I was doing
it was not 'in error')

From what I can tell, it's really a more general statement that
"the news groups on openwatcom are /not/, generally speaking, populated."

since it's jiri's kid, and noone else has access; even though I have an
account and could be granted shared privileges; looks like a good place
for that contact is here; and bring attention to corner conditions that
could be fixed quite simply; across all previous versions also.

I don't see that any of this was 'my' error;
1) I apparently had read the docs, and followed the docs... I was aware of
other methods from experience, but that's not how CMake was
implemented...probably because they followed the docs *I do want to thank
you for making me go look up 'wlib' in the docs and see why it was I was
doing it that way*
2) right, so following the announcement of 2.0; and testing it for
viability before recommending it as an upgrade, I can't provide feedback
here about an issue with that; and it was a new file, which my unchanged
code somehow changed because of something I did and included a new
header? No... it was auto included by the tools; which sharing the same
name, and being Jiri's and having had an announcement here... would seem
to be the place to make that note; since there are no other shared
developers on that source page (that I could see).


so the mistake was... using a public communication channel with Jiri? no
that can't be it... so... what happened?


And now I just get to think of how wonderful news groups are, because I'm
sure noone's actually pulling this message content having long since given
up on you.
Leif Ekblad
2014-03-12 18:24:19 UTC
Permalink
Raw Message
I tried to fix this issue a while back by removing some error-codes, but it
was reverted :(

I agree that this is a bug. Wlib should NOT produce errors if there are no
exports.

For target RDOS, I fixed the issue in the IDE by adding a default
initialization module for DLLs and messing with the makefiles. The same
thing could be ported to other platforms. But, really, the issue should be
fixed (it's not an error to process a DLL without exports with wlib).

Leif Ekblad
Post by J
On Tue, 25 Feb 2014 09:57:23 -0800, Paul S. Person
Post by Paul S. Person
Post by J
Post by Jiri Malak
I don't see any problem.
You try to create DLL without any export, then wlib report it as error if
generate import library.
If you want export some symbol from DLL you must specify it, either to
compiler by __declspec(dllexport) or to linker by export directive.
Let me clarify; perhaps it's indeed valid to not have entry points. But
then an exception needs to be made if there is code in __segname("XI")
<snip code defining>
Post by J
PRIORITY_PRELOAD( InitMyCode )
but no LibMain() (and, no, "InitMyCode" is not renamed to "LibMain" by
the PRIORITY_PRELOAD macro).
Have you tried inserting the required function
BOOL APIENTRY LibMain( HANDLE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved )
(with an implementation that at least returns a BOOL) into the DLL?
See the Programmer's Guide Help "NT: Creating a Sample Dynamic Link
Library". Not working with NT? Find the equivalent page in the
Programmer's guide for whatever you /are/ using.
The result is clear: you cannot have a data-only DLL: it must contain
a LibMain() implementation. But that is not to say that LibMain() has
to do anything (except return a BOOL), or that the rest of the DLL
cannot be purely data.
Note: Some compilers create (or have in the past created) one
automatically if none is present, fostering the illusion that a
data-only DLL is possible. Open Watcom is not one of them.
Note: Technically, every DLL is supposed to have a termination
function, but the vast majority, if not all, of compilers create that
automatically. DLLs were originally intended to work in 16-bit
non-enhanced Windows environments, and both LibMain() and the
termination function had things that had to be done in that context,
IIRC.
Really the issue is Open Watcom is the ONLY compiler that has an issue
with this.
GCC generates DLLs with no exports just fine
msvc also
In face watcom has no issue there except when the wlib tries to process
the empty DLL
Which works just fine. And I have no issue with any usage.
This works under for a C++ example too that doesn't exploit compiler
specifics
(I have to use a segment in msvc)
(gcc provides a __attribute((constructor)) which sort of works, but has no
priority itself)
There is no problem running code at this point, as long as you repsect all
rules of DllMain or LibMain. Do not create a thread... etc. But I don't,
I just add the real entry point into a list, so right at the beginning I
can call the properly scheduled inits that came in dynamially
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
J
2014-03-13 20:59:22 UTC
Permalink
Raw Message
Post by Leif Ekblad
I tried to fix this issue a while back by removing some error-codes, but it
was reverted :(
I agree that this is a bug. Wlib should NOT produce errors if there are no
exports.
For target RDOS, I fixed the issue in the IDE by adding a default
initialization module for DLLs and messing with the makefiles. The same
thing could be ported to other platforms. But, really, the issue should be
fixed (it's not an error to process a DLL without exports with wlib).
Leif Ekblad
That's sad to hear.
The only argument comes from the conservative side where 'the change may
affect others relying on that error'.

1) their software is already developed, and has the appropriate code to
make exports working now; If they upgrade, it would continue to work. If
they make a change that causes all exports to suddenly disappear, it would
likely show up...
a) when they link other objects/libraries against it and it fails 'entry
point not found'
b) when they load the new library dynamically and they are unable to get
entry points that used to work

2) their software is being developed...
a) (see 1a above)
b) (see 1b above)

If entry points disappear, and that is no longer an error, it is likely
that the entry points were relied on by other code, and will quickly
indicate a failed build; at which point you can scan for warning or error
and discover the difference... or compare the build against an old build...
J
2014-03-13 21:05:04 UTC
Permalink
Raw Message
re: demote wlib error to warning...

I also realize that such an insignificant change doesn't even merit a RC
or barely even a patch build. I'm aware of the work to create a package.
But there are other things that are broken; leaving pack set at 8 thereby
overriding user preferences; or..

is it required that you have a '#pragma pack' in your code to make sure
you get the correct alignments? Is it therefore a user error to not have
used that to protect themselves?
Paul S. Person
2014-03-14 15:54:29 UTC
Permalink
Raw Message
Post by Leif Ekblad
I tried to fix this issue a while back by removing some error-codes, but it
was reverted :(
I agree that this is a bug. Wlib should NOT produce errors if there are no
exports.
This, of course, presupposes that wlib was intended, when first
designed, to produce implibs when no exports are present.

Perhaps the problem is, not that it issues an error and works anyway,
but that, having issued an error, it then proceeds to function.
--
"Nature must be explained in
her own terms through
the experience of our senses."
Tomasz Kępczyński
2014-02-23 16:16:36 UTC
Permalink
Raw Message
Post by J
I'll test it soon enough ; but any chance this code works?
struct name_and_id_params
{
CTEXTSTR name;
THREAD_ID thread;
};
struct name_and_id_params params = { name, thread };
instead of
struct name_and_id_params params;
params.name = name;
params.thread = thread;
(compile error; required constant expression)
If you are talking about initialization of local function variable in C
then use -aa option for this to work.

Tomek
J
2014-02-25 00:36:17 UTC
Permalink
Raw Message
On Sun, 23 Feb 2014 08:16:36 -0800, Tomasz K=C4=99pczy=C5=84ski <***@j=
ot23.org> =
Post by J
I'll test it soon enough ; but any chance this code works?
struct name_and_id_params
{
CTEXTSTR name;
THREAD_ID thread;
};
struct name_and_id_params params =3D { name, thread };
instead of
struct name_and_id_params params;
params.name =3D name;
params.thread =3D thread;
(compile error; required constant expression)
If you are talking about initialization of local function variable in =
C =
then use -aa option for this to work.
Tomek
Oh excellent, I can do that.
I don't do it very often... but this time it passed visual studio and gc=
c, =

and was something only watcom complained about as an error.

-- =

Using Opera's revolutionary email client: http://www.opera.com/mail/
Loading...