> trunk/reactos/dll/win32/kernel32/lang/pl-PL.mc (with props)
IMO is not a good idea to use different mc files for every language. MC file
format is specially designed to hold all the languages in the same file,
also our current WMC implementation does not support splitting translation
across multiple mc files. AFAIK Physcious was working on implementing that
feature to our WMC but even in that case there is no easy way to support
them at rbuild level without introducing a hack, also MS's WMC does not
support it so I think we should keep it to the lowest common denominator and
avoid future compiler compatibility problems as there isn't any significant
advantage on it.
/Marc
jimtabor wrote:
>when WindowObject->Wnd is NULL and WindowObject is not NULL
> it crashes in vis.c line 89.
[...]
>Since this crash is started in GetDCEx with a NULL "Window"
>call leaves me with a bad taste. The code was written prior to
>having Desktop support, later hax. So having null window
>associated with DCE is okay then, not now.
>
>Any Ideas?
Isn't this the case where it in Windows originally got the meaning
"use the desktop window", that later became a compatibility hack where
"NULL isn't a cool HWND, but due to the many programs using it, we'll
automatically give the user the DC for the (currently visible) screen"
(or possibly the desktop associated with the thread)?
--
Mike
Hi,
>From this patch
http://svn.reactos.org/svn/reactos?view=rev&revision=30477, I found
when WindowObject->Wnd is NULL and WindowObject is not NULL it crashes
in vis.c line 89. This patch is okay. My best guess, when Wnd is null
that means the window is on the way of removal. Luck of the thread? I
can patch and protect the while loops in vis.c but the crash moves to
another place based on the same null Wnd problem. Since this crash is
started in GetDCEx with a NULL "Window" call leaves me with a bad
taste. The code was written prior to having Desktop support, later
hax. So having null window associated with DCE is okay then, not now.
Any Ideas?
Thanks,
James
Hi list,
attached is a patch to update the crypt-related part of advapi from
wine.
Hope this patch is useful. It's less intrusive than earlier patches from
me.
Please use it,
Christoph (aka egore on IRC)
Hi list,
on my way on comparing wine with reactos I found several differences
which were cleanups in wine. Attached is a patch to merge over theses
changes.
Regards,
Christoph Brill
Hi list,
I tried to sync shdocvw today. Our version is quite different from what
I found in wine. Both seem to have started from a similar point but both
got some development done. I'm not sure I'm doing anything correct here,
but to outline my changes (and later on the issues):
- Import the new "class hierarchie"
(ConnectionPointContainer->DocHost->WebBrowser)
- stuff like IPersistMemory, IOleCommandTarget, IHlinkFrame, IDispatch,
IServiceProvider
- URL-History and Navigation (Forward, Backward)
Issues:
- I commented out regsvr.c because factory.c had similar functions. I'm
not sure which one is better, but whichever we choose it should be put
in regserv.c and merged back to wine.
- DllGetClassObject in shdocvw_main.c commented out in favour of
factory.c. Same as above.
- I removed "extern const GUID CLSID_InternetShortcut;" from
include/psdk/isguids.h. We needed CLSID_InternetShortcut to be static
in factory.c.
You see: factory.c causes me a major headache. I'll see if I can fix
these issues but I really like one with knowledge(!) to look over the
patches and at least tell me: Hey, what you are doing is (more or less)
right/wrong. Feedback please!
Thanks,
Christoph Brill
Hi list,
attached is a patch to update msvcrt20 against wine. It changes:
- use the .spec file from wine to generate the .def
- Add some CDECL's
That's it,
Christoph Brill