I dont know for sure but I believe modern versions of SecuRom use kernel
mode code/drivers. If so, the work done on NTOSKRNL for SafeDisk might work.
I havent seen any microsoft source or any other dirty stuff but what I know
is that the DirectX dlls call functions like ddentryxx and gdientryxx in
gdi32.dll. (there is a ddrawgdi.h file in the platform SDK I have and there
is also documentation on MSDN for them)
These then call system calls
etc.), and we need better support for the various code obfuscation
tools, it's probably the number one cause of apps not even starting
today.
Does that include things like Safedisk, Securom and other cd copy protections?
As far as possible, yes. I think the goal for 1.0 should be that
anybody has to be able to try Wine and see that it's for real. This
means they must not be stopped either by not being able to configure
it, or by apps failing to even start.
I look forward to a day when vanilla WINE is good enough
I believe the strikethrough uppercase W is a korean Won sign.
There is an article on one of the microsoft blogs (which I cant get to
right now) that explains why the Yen and Won signs have this relationship
with the backslash.
Pretty much all scanners I have seen implement a standard API (such as
TWAIN or whatever the scanners and cameras folder maps to) which programs
like Photoshop and GIMP use to talk to the scanner directly.
On linux, it seems like the equivelent is SANE.
To me, the right answer is for WINE to
Question: Why doesnt WINE just have a complete implementation of the core
printf logic itself? With all the differences between printf as defined
in ANSI C and as is present on the systems WINE runs on (i.e. linux,
darwin, solaris, BSD etc) and printf as implemented by Microsoft in their
C
Feel free to go ahead and write one if you like :)
One assumes ReactOS needs such a function, how do they do it?
Would getting the ReactOS guys to re-licence as LGPL (if such a thing is
even possible) their printf base code work? (is what they have even any use?)
Just a thought :)
Frank Richter wrote:
Frank Richter [EMAIL PROTECTED]
Add theming support. When comctl32.dll is attached to a thread, a CBT
hook is set up for the current thread which intercepts all window
creations. There, the class name of the window is checked. In case of a
known class, the window is
+BOOLAPI FtpCommandA(HINTERNET, BOOL, DWORD, LPCSTR, DWORD_PTR, HINTERNET *);
+BOOLAPI FtpCommandW(HINTERNET, BOOL, DWORD, LPCWSTR, DWORD_PTR, HINTERNET *);
Was it intentional that FtpCommand doesnt have a WINELIB_NAME_AW #define?
The tricky part (in all of these schemes really) is knowing how to
handle the coordinates. They'd have to be put in the msgid together with
the actual stuff to translate. But in fact you can't know what to set
the coordinates to unless you see a graphical representation of the
dialog... This
Johan Dahlin suggested GTK+ theming integration as a project on IRC, and I
agree that this would probably be about the right level of
difficulty/work. Or rather, supporting theming in our widget toolkit, even
if the actual GTK+ bridge wasn't written.
IMO, such themeing should be done via a
From what I understand, there are 3 ways to do copy protection in WINE (at
least for copy protection that needs a kernel driver to work):
1.Implement a WINE implementation of that kernel driver (in the same way
various stock windows kernel drivers have been implemented). Problem with
this is
Well, umm, anyone an idea how Windows does this? ;-)
(I assume that Windows has to do the same thing somehow)
When I worked on the GDI system object mechanisms, I investigated that,
but didn't find anything which could have done that.
OTOH I'd bet that the Windows way of achieving this is equally
Its highly likely that GCC and WINE are already infringing on some software
patent somewhere (since its well nigh impossible not to in the current
patent everything you can climate inside a number of big companies)
What makes this particular borland patent any different?
Does OpenWatcom implement this kind of SEH exception handling?
If so, it means they are either illegally using the borland patent (quite
possible) or they have some kind of licence to use it (in which case we
should find out more)
Why doesnt someone just implement the microsoft SEH keywords and extentions
into GCC like it should be?
Same with anything else microsoft that WINE or ReactOS needs (e.g.
_declspec(thread) support)
What I am doing here is clean-room reverse engineering.
Essentially it involves taking existing binary modules and sources of
information and writing up what they do in a way that isnt violating the
copyright on the origonal (IANAL but I dont think what I posted violates
the copyright on the
ok, further to what I mentioned before about RegisterUserApiHooks (and
poking around in uxtheme.dll), I see the following things being hooked by
uxtheme (at least it seems to be the complete list)
GetScrollInfo
SetScrollInfo
EnableScrollBar
SetWindowRgn
DefWindowProcW
DefWindowProcA
PreWndProc
What I strongly suspect happens is this:
1.The themes service is always loaded and running and holds the theme data
(and it contains details of which .msstyles file to use)
2.At some point (either at startup if the changes are global or when an app
loads if the changes are app specific, I cant
Also related to this (as pointed out in IRC) is Activation Contexts/SxS
stuff), we need this to make sure the correct window classes are used at
the correct time.
Doing a dump of the imports table from native uxtheme.dll from my XPSP2
box, I see that it imports a function from user32.dll called
RegisterUserApiHook which is totally undocumented (neither MSDN or google
show up any info about what it does).
This function is only present in Windows XP (and I
I found that page.
But what I want to know is if there is one overall list (at msdn or
elsewhere) of all the things Microsoft has documented as a result of the
various lawsuits in various places (US, EU etc). I didnt see anything
specific on the MSDN link that pointed to such a thing.
Does anyone have any links to these documented only because Microsoft have
to type functions (like NtCreateFile etc)?
How will this work affect Direct3D8 apps?
Will this work make those apps run any better (or is work to do that being
done?)
Also, how does the work we have here in this project compare to what
TransGaming have as far as Direct3D functionality?
I expect that the check program will be reverse engineered and cracked to
return genuine even for pirate copies in fairly short order.
Either that or the pirates will just grab the patches and circulate them on
the pirate sites anyway.
I remember some people talking about some kind of unicode tables that
WINE has but that dont match with the MS implementation.
What are the tables for?
And what API call(s) are involved?
Looks like the new misc.c is missing from the patch...
In light of e.g.
http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html
I would like to suggest the following header ideas.
Currently MingW has:
1.A set of headers that contain a copy of part of the platform SDK
2.Some extra stuff (like that ntdll.h)
3.A set of headers that
Yeah, I know, it's just that it's not my code and I'm not certain that
the authors will be releasing an update. There's a rumor of one but no
certainty, as the company (a game publisher) refuses to make any
announcements about what it's working on.
Does the crash happen on a real windows box?
Does the transgaming WINE have anything above what stock WINE has when it
comes to OpenGL apps/games?
I dont know how this stuff works on linux so my suggestion may be wrong but
here goes.
Basicly, my suggestion is that any joystick that is visible to linux apps
be made visible to windows apps via DirectInput joystick APIs.
This eliminates the need for WINE to care about USB and such.
This would be great but how do you do with COM objects. What did you do
for your direct3d hooking.
I remember someone on the ReactOS team gave me the hook related stuff. (I
cant remember who)
What I do is to modify the target to load the hook dll instead of the
normal dll. The hook dll then
Basicly, when emulated windows version is set to NT4, 2000, XP or 2003,
WINE should pretend to apps that its running on NTFS.
If running as 95,98 or ME, it should pretend to apps that its running on FAT32.
Or better yet, add an option for this (with my suggestions being the default)
Just an idea
Is anyone working on getting sutable-to-use-in-wine versions of these?
Would having these benifit OLE apps?
This Marlett replacement sounds like it would be usefull for ReactOS also.
How about this.
Use #ifdef stuff so that when building on WINE, it uses unix sockets.
But when building on win32 (which would include MingW and ReactOS), it uses
winsock.
Has anyone given thought to using the Microsoft SDK samples (e.g. DirectX
samples) to improve WINE?
i.e. take a particular sample and work away at it untill what you get in
WINE matches what you get in Windows.
Although I suspect that there are things that the MS samples dont cover :)
BTW, implementations for WCSToMBEx and MBToWCSEx can be found here:
http://article.gmane.org/gmane.comp.emulators.wine.patches/5049/
I dont have a usable setup to turn them into proper patches but if anyone
wants to use them for WINE, go ahead and grab them.
Not sure how usefull they would be
ReactOS uses linker magic.
My point is that there is no valid reason for the WINE code in kernel32 not
to use RtlAllocateHeap since the WINE kernel32 code is only intended to run
on ReactOS (where RtlAllocateHeap is available) and WINE (where
RtlAllocateHeap is available). Therefore, re-writing
I just posted a patch to the reactos list that gets whatever comctl32.dll
reactos has building with -Wall -Werror. But I dont have a WINE tree or any
way to port these fixes over to WINEHQ. Can someone do it for me?
Personally, I would like to see Transgaming release all the code that they
have that is not copy-protection and is not directx under a true
open-source licence.
In particular, any enhancements (whatever they may be) to OLE and COM.
I think that Transgaming, WineHQ, Codeweavers and ReactOS
I am working on ReactOS and would like to take the code in
static void X11DRV_DIB_SetImageBits_RLE4( int lines, const BYTE *bits,
DWORD width, DWORD dstwidth,
int left, int *colors,
Is there a way to do this?
I want to use it on various PE files (DLLs, EXEs etc) to see if any of them
import some of the functions for which I dont yet have a prototype :)
None whatsoever, the driver reimplementation is clearly a DMCA
violation. The proper way to do that is to somehow load the driver and
let it perform all the checks it wants to perform; a dummy driver that
returns magic values to bypass the checks is not acceptable.
From what I know about copy
Is the use of dumpbin /EXPORTS a sutable way to get information?
Would e.g. doing this then using that to generate e.g. an import library be
legally ok or not?
IMO its a waste for both WINE and ReactOS to have 2 different
implementations of MSVCRT.DLL/CRTDLL.DLL
Is there any valid reason not to either remove one and have both projects
use the other or to merge both and come up with one dll?
IANAL but here are some examples of things that I think are things that the
law was intended to protect:
1.A real-estate database with information on many different houses.
2.The database at e.g. amazon.com containing details about a whole bunch of
books
3.A database containing details of
Everything that's LGPL should be listed on the above page. Additionally,
code in ReWind is X11. Anything else in WineX may be assumed AFPL, but
may also be released as X11 at TransGaming's discretion. I think most
non-DirectX code (and even a limited subset of the DirectX code) could
be released
From what I understand, if you download the WineX source tree, you get
code under LGPL, code under X11 and code under APL (which is basicly a
licence chosen to make sure that others cant just grab those bits and use them)
Does anyone know which bits are under APL? I know the directx bits are
http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/
It indicates that there is a table that holds GDI internals and gives
details about it.
I can also confirm that the API call GdiQueryHandle in gdi32.dll retrieves
pointer to this handle table.
Does anyone have any more info related to how
1.where do I get the most complere DirectX OLE/COM header files? WineHQ
CVS or somewhere else?
2.how complete are they?
3.what version of DirectX are the header files targeted at?
52 matches
Mail list logo
