Generic behavior is to
1) use .spec for DLLs (because usually DLLs are shared with Wine,
which uses the same format), but for msvcrt it was not possible.
2) implement a stub as soon as possible whenever it is hit
WBR,
Aleksey Bragin.
On Dec 19, 2007, at 4:20 PM, Sylvain Petreolle wrote:
> Could these stubs be added to other dlls too ?
>
> For example, audiosrv crashes is being killed by EXCEPTION_WINE_STUB,
> because setupapi misses the CMP_RegisterNotification function.
>
> Kind regards,
> Sylvain Petreolle (aka Usurp)
Could these stubs be added to other dlls too ?
For example, audiosrv crashes is being killed by EXCEPTION_WINE_STUB,
because setupapi misses the CMP_RegisterNotification function.
Kind regards,
Sylvain Petreolle (aka Usurp)
Je ne suis pas d'accord avec ce que vous dites, mais je me battrai jusqu'à la mort pour que vous ayez le droit de le dire.I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - VoltaireRun your favorite Windows apps with free ReactOS : http://www.reactos.orgListen to non-DRMised Music: http://www.jamendo.com
On Dec 18, 2007 6:03 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> I merged it, taking in account winebuild's changes (using output()
> function for example), so in 31300 it seems to work correctly.
>
> I didn't really understood that AJ's message - Wine does not need
> stubs as stubbed functions at all, but rather want all of them to be
> manually implemented in a standalone .c file as stubs? or?
As we discused on IRC he wants to do away with pseudo-stubs or at
least does not think they should be used in a PE build. I tend to
agree a function should either be implemented, fully stubbed or not
there at all unless an application is proven to need it. Needless
stubbing results in breakage when an application calls
GetProcAddress/LoadLibrary and would normally fail with grace if the
function is not there. Instead it can hit one of these fake stubs,
assume its safe to keep working and blow up on you.
As for your other question about decoration in mangled symbols for
stdcall functions I am not quite sure I understand it. The only
decorated functions I saw in the spec file were all cdecl. There were
others that are exported variables and some stdcall functions but they
did not have decoration unless I just missed it.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I merged it, taking in account winebuild's changes (using output()
function for example), so in 31300 it seems to work correctly.
I didn't really understood that AJ's message - Wine does not need
stubs as stubbed functions at all, but rather want all of them to be
manually implemented in a standalone .c file as stubs? or?
WBR,
Aleksey Bragin.
On Dec 18, 2007, at 5:11 AM, Steven Edwards wrote:
> On Dec 17, 2007 6:36 PM, <cfinck(a)svn.reactos.org> wrote:
>> Every change I try for fixing the build in one component breaks
>> the build for another component.
>> winebuild wasn't synchronized completely to the Wine version
>> anyway, and the current Wine version removed support for the --
>> pedll option we use, so a full clean sync isn't possible.
>
> Can you merge the --pedll patch up to the trunk rather than reverting?
> You might want to comment out the stubs anyway or add real stubs and
> submit them to wine as per Alexandre's rejection of the patch by GvG
>
> http://www.winehq.org/pipermail/wine-devel/2004-December/031978.html
>
> Thanks
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo
On Dec 17, 2007 6:36 PM, <cfinck(a)svn.reactos.org> wrote:
> Every change I try for fixing the build in one component breaks the build for another component.
> winebuild wasn't synchronized completely to the Wine version anyway, and the current Wine version removed support for the --pedll option we use, so a full clean sync isn't possible.
Can you merge the --pedll patch up to the trunk rather than reverting?
You might want to comment out the stubs anyway or add real stubs and
submit them to wine as per Alexandre's rejection of the patch by GvG
http://www.winehq.org/pipermail/wine-devel/2004-December/031978.html
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
On Dec 16, 2007, at 4:10 PM, Marc Piulachs wrote:
> Hi Alex,
>
> Let me see if I understood this correctly. The problem is not
> really on
> manually choosing the base address, the problem is that module's
> "baseaddress" attribute is optional, even when the module is of type
> "win32dll", if this attribute is empty rbuild sets a common default
> base
> address (0x10000000 for win32 dll's).
No, the problem is exactly choosing the address: modules overlap with
each other, and manually calculating baseaddresses often doesn't
work. Alex proposed to automate this process and do a
baseaddress.rbuild file generator.
There are not many dlls with baseaddress missing, and if it's
missing, it should be added to those (in trunk).
> AFAIK we are using the same base address that the equivalent
> component has
> on windows so auto generating it using any sort of tool is not
> really an
> option.
Not really, in most cases (might be with a few exceptions), it's not
possible to use exactly Windows' base address (because size of our
modules and windows modules often differs). The problem is to
distribute the dlls in the memory address space so that they don't
overlap.
As for baseaddress in xml form - baseaddress is a module's property,
it's not a standalone object which is part of the module. I don't see
why it should be given a standalone tag (maybe I'm missing something).
WBR,
Aleksey Bragin.
Hello,
On Dec 17, 2007 5:01 PM, <cfinck(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=31296&view=rev
> Log:
> Rename DSOUND_DllRegisterServer to DllRegisterServer and DSOUND_DllUnregisterServer to DllUnregisterServer. (the same is already done in the other DirectX DLL's with SPEC files)
> I wonder how dsound.dll could be compiled in the past cause the SPEC file never referenced to these functions.
Maybe there was a bug in older versions of binutils. Perhaps it was
ignoring unresolved exports marked PRIVATE.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I have thought about localizing our messagetables, like kernel32's
errorcodes.mc
Now the question is: how do we do this?
We could simply add all localisations inside the current file without
changing anything else in the build process. I didn't test if it works,
but it should. But it would lead to huge files full of different
languages and would also remove the possibility for custom selection of
the languages that are compiled.
I would prefer to go the way we do with other localisation: put
different .mc files in the lang subfolder. But afaik mc files don't
allow inclusion of external files, so we need some build process that
compiles the different mc files into rc files and include those into a
main rc file. Currently our mcs are defined in makefile. This should
move to the rbuild files and rbuild should compile the mc files and
create the needed rc:
<module...>
...
<file>foo.c</file>
<file>foo.rc</file>
...
<autoresource>auto.rc</autoresource>
<localization isoname="de-DE">lang/de-DE.rc</localization>
<msgtable isoname="de-DE">lang/msgtable-de-DE.mc</msgtable>
</module>
rbuild would generate <intermediate dir>\lang\msgtable-de-DE.mc.rc and
auto.rc containing includes to the generated files. IMO auto.rc should
be the file that is compiled, including all localizations and the
unlocalized resource file.
#include "lang/de-DE.rc"
#include "lang/msgtable-de-DE.mc.rc"
If I understood Fireball correctly, this is also msvc compatible. And
if not, rbuild just would have to generate the files differently.
Some ideas for simplifying the rbuild definitions: Instead of <file>,
<localization> and <msgtable> we could simply use <file> for
unconditional compilation, <file locale="en-US"> for localized
conditional compilation. And then let rbuild decide from the file
extension what to do with it. resources/messagetables could
automatically be included in an autogenerated rc file, without
explicitly defining it in the rbuild file.
Regards,
Timo
Is this code for human ?
"@@ -81,7 +81,7 @@
* if they forget set it, the ddraw will autoamtic
* set it for system memory.
*/
- if ((pDDSD->dwFlags & DDSCAPS_SYSTEMMEMORY) != DDSCAPS_SYSTEMMEMORY)
+ if ((pDDSD->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY) ==
DDSCAPS_SYSTEMMEMORY)
{
pDDSD->dwFlags = pDDSD->dwFlags | DDSD_LPSURFACE;
}"
On Dec 16, 2007 1:46 AM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Sun Dec 16 03:46:43 2007
> New Revision: 31268
>
> URL: http://svn.reactos.org/svn/reactos?rev=31268&view=rev
> Log:
> fix a typo
>
> Modified:
> trunk/reactos/dll/directx/ddraw/Surface/createsurface.c
>
> Modified: trunk/reactos/dll/directx/ddraw/Surface/createsurface.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/directx/ddraw/Surface/…
>
> ==============================================================================
> --- trunk/reactos/dll/directx/ddraw/Surface/createsurface.c (original)
> +++ trunk/reactos/dll/directx/ddraw/Surface/createsurface.c Sun Dec 16
> 03:46:43 2007
> @@ -81,7 +81,7 @@
> * if they forget set it, the ddraw will autoamtic
> * set it for system memory.
> */
> - if ((pDDSD->dwFlags & DDSCAPS_SYSTEMMEMORY) != DDSCAPS_SYSTEMMEMORY)
> + if ((pDDSD->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY) ==
> DDSCAPS_SYSTEMMEMORY)
> {
> pDDSD->dwFlags = pDDSD->dwFlags | DDSD_LPSURFACE;
> }
>
>
>
--
MVH
Simon Blomqvist
Tel - 0735307474
IT www.AgentEyes.com
Internet Café www.cafe.agenteyes.com
Konst www.konstgrossisten.com/
Jag ringer gratis med www.skype.se mitt id är: simonblomqvist
Hi!
Let us start on this now.... It is time to restructure the GDI OBJ
Lock Unlock mess! Don't wait for me.
I'm working on the DCE issue which is a mess due to gdiobj.c over
think object locking system. The new
ideas I have will not be compatible with the current system.
Thanks,
James
