Hi List
I'm finally on my ass trying to redo the ATL/MFC Job from a year ago.
This time I decided to start on windows with MinGW than move the MinGW
makefiles to be used with winegcc. It is a grate test for winegcc and
the windows API in general.
Well it turns out to be a very big test for MinGW as well. The headers
are in a very bad shape. I had to use Wine headers to be able to
compile. but I'll leave all that to a later e-mail.
[Q] I'm (well ATL is) using __attribute__((weak)) (translated from
__declspec( selectany) ) for instantiation of members and variables in
headers. I had no problem with it On GCC in Linux (gcc 3.2.2). On MinGW
I get below warning. And needless to say that I get a Linker duplicate
symbol Error. Any Ideas on how to overcome this. Is this a g++ only bug?
<g++ warning example>
H:\Dinosaur\OneSource\MinGWStudio\msvc\atl\include\atlhost.h:56:
warning: weak
declaration of `UINT ATL::WM_ATLGETCONTROL' not supported
</g++ warrning example>
<linker error example>
H:\Dinosaur\OneSource\MinGWStudio\msvc\atl\include\atlwin.h: multiple
definition of `ATL::WM_ATLGETCONTROL'
H:\Dinosaur\OneSource\MinGWStudio\Samples\AtlWB\Debug\aboutdlg.o(.bss+0x1c):H:\Dinosaur\OneSource\MinGWStudio\msvc\atl\include\atlwin.h:
first defined here
</linker error example>
Please forgive me for sending it here and not to MinGW list. But I feel
more at home here than there. ( :( )
Free Life
Boaz
--- gvg(a)svn.reactos.com wrote:
> Sync to Wine-20050211
> - add support for Edit boxes in MSI dialogs
.....
Just a short note. With this patch most installars using MSI might be able start on ReactOS but
there seems to be some sort of communication issue when they try to tell services to load msiexec.
I added a Windows Installer service here in my tree but still have not had much luck. If someone
wants to sync msiexec.exe with winehq and have a look we can then see how far iTunes and Office
will get.
Thanks
Steven
__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com
weiden(a)svn.reactos.com wrote:
>The structure layout of self-relative security descriptors may be different from absolute security descriptors depending on the platform. Self-relative security descriptors always use 32 bit offsets while absolute security descriptors use pointers which could be 64 bits.
>
>
>Updated files:
>trunk/reactos/include/ntos/rtl.h
>trunk/reactos/include/ntos/security.h
>trunk/reactos/lib/advapi32/sec/sec.c
>trunk/reactos/lib/rtl/sd.c
>trunk/reactos/ntoskrnl/se/sd.c
>trunk/reactos/w32api/include/ddk/ntifs.h
>trunk/reactos/w32api/include/ddk/winddk.h
>trunk/reactos/w32api/include/winnt.h
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
Well after arguing with me on IRC I'm happy to see that you finally
realized I was right.
Best regards,
Alex Ionescu
Hi,
First of all, what's up with ntvdmpath in the freeloader tree? I fail to
see what it has to do with ROS, much less with freeloader...I'm
recommending removal. Secondly... is there any problem with freeloader
using the ros depends tool instead of deptool? I know before this was
necessary because of different trees, but I would like to share as much
as possible.
Best regards,
Alex Ionescu
arty(a)svn.reactos.com wrote:
>Patch to fix NtCreateSempahore, in the case where the initial lookup
>succeeds. We previously left the function without initializing
>hSemaphore. Patch suggested by me and executed by hpoussin.
>
>
To me it looks totally wrong. First of all, the handle in my tests is
never written if the function fails (just create a testcase where your
application tries to create thousands of semaphore objects to reproduce
it). Second of all you initialize the semaphore object only if creating
it failed, as in you initialize a semaphore object on a NULL pointer.
Third of all you insert a handle to the object no matter if you
previously could create it, so you would end up creating a handle to a
null-pointer.
The previous version I wrote just had one small bug, it checked if
ObCreateObject failed to continue initialization and handle creation
instead of checking if it succeeded. I'm going to revert this version of
NtCreateSemaphore as it introduces even more bugs and adds behavior
neither documented nor reproducable. I guess in case an application
failed due to this function it was because of the fact that the function
succeeded and didn't return a handle to a semaphore object even though
one was created.
Best Regards
Thomas
The good news is that vncviewer is oh so close to running. If you apply
this patch it *does* run, but I think the patch is wrong. Hopefully,
after illustrating a wrong solution somebody might be able to see a right
one.
The problem it runs into is that the 2nd 'Alertability failed' message in
KeWaitForMultipleObjects is always triggered, which makes vncviewer unable
to display anything.
If i #if 0 that block out, then it appears to work fine. I suspected that
either we were being too conservative or there are too many APCs happening
on that thread, and this confirms that one of the suspicions is true.
The attached patch illustrates the probably broken solution.
Screen: http://64.81.145.152/~arty/vncviewer2.jpg
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
Hi,
did you know it is possible to configure Subversion, such that it automatically sets the correct properties for new checked in files? It looks at the file extensions to set properties such as the EOL style, mime type and to configure keyword expansion strings. For Windows the settings are stored in the registry, and for Unix they are stored in the file ~/.subversion/config. I attached a registry import file as an example, which contains settings I am using myself.
Regards,
Martin
> From: weiden(a)svn.reactos.com
>
> moved smdll to rosrtl. We just _can't_ have separate dlls for
> everything internal, that's what static libraries are for.
> Unless we want a dll hell even worse than necessary...
I think you are acting unbelievably rude here. Please revert your change and
discuss this on the mailinglist first.
Gé van Geldorp.