MinGW - Minimalist GNU for Windows

On 26.04.2011 16:18, RSPsoftware wrote:
>
> dumppe that is a executable analizer and disassembler detects a dll created with mingw compiled with
> 	windres -o versio_n.o -O coff versio_n.rc		gcc -DDPRINTF -enable-stdcall-fixup -shared -O3 \	-Wmissing-prototypes -o rsputil.dll \	versio_n.o def.def  rsputil.c e_malloc.c \	dprintf.cas:Subsystem                                   0003 (Console)while when compiled with vc it is detected as:Subsystem                                   0002 (Windows)
> What implicatons it may have in the execution of this dll that may result in a different behavior ?
>
Try using -mwindows linker option. I'm surprised that you have this 
problem, since MinGW would not have been able to compile a program with 
CONSOLE subsystem when you don't have a main() (you have WinMain() and 
not main(), right?).

it is a dll,it don´t have a main or a WinMain, just a Dllmain that indeed is optional for compilation

arab

http://nomade.sf.net

--- Em ter, 26/4/11, LRN <lrn1986@...> escreveu:

De: LRN <lrn1986@...>
Assunto: Re: [Mingw-users] dll created in a different way
Para: mingw-users@...
Data: Terça-feira, 26 de Abril de 2011, 10:40

On 26.04.2011 16:18, RSPsoftware wrote:
>
> dumppe that is a executable analizer and disassembler detects a dll created with mingw compiled with
>     windres -o versio_n.o -O coff versio_n.rc        gcc -DDPRINTF -enable-stdcall-fixup -shared -O3 \    -Wmissing-prototypes -o rsputil.dll \    versio_n.o def.def  rsputil.c e_malloc.c \    dprintf.cas:Subsystem                                   0003 (Console)while when compiled with vc it is detected as:Subsystem                                   0002 (Windows)
> What implicatons it may have in the execution of this dll that may result in a different behavior ?
>
Try using -mwindows linker option. I'm surprised that you have this 
problem, since MinGW would not have been able to compile a program with 
CONSOLE subsystem when you don't have a main() (you have WinMain() and 
not main(), right?).

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...

On 26.04.2011 17:59, RSPsoftware wrote:
> --- Em ter, 26/4/11, LRN<lrn1986@...>  escreveu:
>
>> On 26.04.2011 16:18, RSPsoftware wrote:
>>> dumppe that is a executable analizer and disassembler detects a dll created with mingw compiled with
>>>      windres -o versio_n.o -O coff versio_n.rc        gcc -DDPRINTF -enable-stdcall-fixup -shared -O3 \    -Wmissing-prototypes -o rsputil.dll \    versio_n.o def.def  rsputil.c e_malloc.c \    dprintf.cas:Subsystem                                   0003 (Console)while when compiled with vc it is detected as:Subsystem                                   0002 (Windows)
>>> What implicatons it may have in the execution of this dll that may result in a different behavior ?
>>>
>> Try using -mwindows linker option. I'm surprised that you have this
>> problem, since MinGW would not have been able to compile a program with
>> CONSOLE subsystem when you don't have a main() (you have WinMain() and
>> not main(), right?).
> it is a dll,it don´t have a main or a WinMain, just a Dllmain that indeed is optional for compilation
Oh, i haven't noticed the 'dll' part. And the actual question about the 
implications. Sorry. Lots of things on my mind right now.

(You DID try -mconsole and/or -mwindows though? Does it make a 
difference? Would be a good thing to know whether these options affect DLLs)

As for implications...i'm not aware of any. OTOH you can export 
functions from an executable, that is - use an executable file as a 
library. So it MIGHT be technically possible (unless someone can give me 
a prooflink to PE specs that shows otherwise) to execute a DLL (instead 
of importing functions from it)...And that wouldn't work without main() 
or WinMain() anyway...so, i guess subsystem type still doesn't matter.

And since we're talking about it...have you ever tried to exec() a DLL? 
Or use CreateProcess() on it? I didn't (which is why i'm asking).

thanks for your info, I will try to extend these tests to see the results and post it here if relevant
about speed I doubt that it will be affected

arab

http://nomade.sf.net

--- Em ter, 26/4/11, LRN <lrn1986@...> escreveu:

De: LRN <lrn1986@...>
Assunto: Re: [Mingw-users] dll created in a different way
Para: mingw-users@...
Data: Terça-feira, 26 de Abril de 2011, 11:19

On 26.04.2011 17:59, RSPsoftware wrote:
> --- Em ter, 26/4/11, LRN<lrn1986@...>  escreveu:
>
>> On 26.04.2011 16:18, RSPsoftware wrote:
>>> dumppe that is a executable analizer and disassembler detects a dll created with mingw compiled with
>>>      windres -o versio_n.o -O coff versio_n.rc        gcc -DDPRINTF -enable-stdcall-fixup -shared -O3 \    -Wmissing-prototypes -o rsputil.dll \    versio_n.o def.def  rsputil.c e_malloc.c \    dprintf.cas:Subsystem                                   0003 (Console)while when compiled with vc it is detected as:Subsystem                                   0002 (Windows)
>>> What implicatons it may have in the execution of this dll that may result in a different behavior ?
>>>
>> Try using -mwindows linker option. I'm surprised that you have this
>> problem, since MinGW would not have been able to compile a program with
>> CONSOLE subsystem when you don't have a main() (you have WinMain() and
>> not main(), right?).
> it is a dll,it don´t have a main or a WinMain, just a Dllmain that indeed is optional for compilation
Oh, i haven't noticed the 'dll' part. And the actual question about the 
implications. Sorry. Lots of things on my mind right now.

(You DID try -mconsole and/or -mwindows though? Does it make a 
difference? Would be a good thing to know whether these options affect DLLs)

As for implications...i'm not aware of any. OTOH you can export 
functions from an executable, that is - use an executable file as a 
library. So it MIGHT be technically possible (unless someone can give me 
a prooflink to PE specs that shows otherwise) to execute a DLL (instead 
of importing functions from it)...And that wouldn't work without main() 
or WinMain() anyway...so, i guess subsystem type still doesn't matter.

And since we're talking about it...have you ever tried to exec() a DLL? 
Or use CreateProcess() on it? I didn't (which is why i'm asking).

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...

> -----Original Message-----
> From: LRN [mailto:lrn1986@...]
> Sent: Tuesday, April 26, 2011 9:19 AM
> To: mingw-users@...
> Subject: Re: [Mingw-users] dll created in a different way
> 
> As for implications...i'm not aware of any. OTOH you can export functions from
> an executable, that is - use an executable file as a library. So it MIGHT be
> technically possible (unless someone can give me a prooflink to PE specs that
> shows otherwise) to execute a DLL (instead of importing functions from it)...And
> that wouldn't work without main() or WinMain() anyway...so, i guess subsystem
> type still doesn't matter.
> 

Well, I'm no windows expert but I did run across this awhile back will doing some research related to "executable" dll's
>From the  Microsoft Portable Executable and Common Object File Format Specification Revision 8.2 section 2.3.2:
    IMAGE_FILE_DLL    The image file is a dynamic-link library (DLL). Such files are considered executable files for almost all purposes, although they cannot be directly run.

This seems to both confirm and refute your assertions.  FWIW I never got around to trying CreateProcess on a dll as I moved on to a different project.  However, I think the solution used was to use rundll32.

-raleigh

On 27.04.2011 18:06, Rinehart, Raleigh wrote:
> LRN:
>> As for implications...i'm not aware of any. OTOH you can export functions from
>> an executable, that is - use an executable file as a library. So it MIGHT be
>> technically possible (unless someone can give me a prooflink to PE specs that
>> shows otherwise) to execute a DLL (instead of importing functions from it)...And
>> that wouldn't work without main() or WinMain() anyway...so, i guess subsystem
>> type still doesn't matter.
> Well, I'm no windows expert but I did run across this awhile back will doing some research related to "executable" dll's
> > From the  Microsoft Portable Executable and Common Object File Format Specification Revision 8.2 section 2.3.2:
>      IMAGE_FILE_DLL    The image file is a dynamic-link library (DLL). Such files are considered executable files for almost all purposes, although they cannot be directly run.
>
> This seems to both confirm and refute your assertions.  FWIW I never got around to trying CreateProcess on a dll as I moved on to a different project.  However, I think the solution used was to use rundll32.
rundll32 can't run just ANYTHING you throw at it. According to [1]:
The programs only allow you to call functions from a DLL that are 
explicitly written to be called by them.

And they call this:
||

  void CALLBACK
   EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);

(which looks like WinMain, but with a different name).

[1] http://support.microsoft.com/kb/164787

LRN wrote:
> On 27.04.2011 18:06, Rinehart, Raleigh wrote:
>> LRN:
>>> As for implications...i'm not aware of any. OTOH you can export
>>> functions from
>>> an executable, that is - use an executable file as a library. So it
>>> MIGHT be
>>> technically possible (unless someone can give me a prooflink to PE
>>> specs that
>>> shows otherwise) to execute a DLL (instead of importing functions
>>> from it)...And
>>> that wouldn't work without main() or WinMain() anyway...so, i guess
>>> subsystem
>>> type still doesn't matter.
>> Well, I'm no windows expert but I did run across this awhile back will
>> doing some research related to "executable" dll's
>> > From the  Microsoft Portable Executable and Common Object File
>> Format Specification Revision 8.2 section 2.3.2:
>>      IMAGE_FILE_DLL    The image file is a dynamic-link library (DLL).
>> Such files are considered executable files for almost all purposes,
>> although they cannot be directly run.
>>
>> This seems to both confirm and refute your assertions.  FWIW I never
>> got around to trying CreateProcess on a dll as I moved on to a
>> different project.  However, I think the solution used was to use
>> rundll32.
> rundll32 can't run just ANYTHING you throw at it. According to [1]:
> The programs only allow you to call functions from a DLL that are
> explicitly written to be called by them.
> 
> And they call this:
> ||
> 
>  void CALLBACK
>   EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);
> 
> (which looks like WinMain, but with a different name).
> 
> [1] http://support.microsoft.com/kb/164787
> 

And EntryPoint is whatever you name it.

-- 
Earnie
-- http://www.for-my-kids.com