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 t
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 s
> 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?
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
> 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 :)
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
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 subcla
+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 wo
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 tha
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 suita
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 m
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 win
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.
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 fi
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 (p
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
Is ReactOS's format the same as Windows. or do you have your own Binary
The answer to "is the reactos registry format the same as windows" depends
on which version of windows you are comparing it to.
Windows 95/98/ME used system.dat and user.dat to store the registry.
NT kernels (NT4, 2000, XP et
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)?
native ntdll.dll requires kernel system call hooks that WINE doesnt support .
native ntdll.dll will never work on WINE.
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.
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 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...
Could WIDL be used alongside MingW to generate IDL files on windows?
What changes, if any, would be needed to WIDL to get it working on win32
and compiling IDL files in a way that MingW can use?
Does MingW have enough of the OLE header files for WIDL to work?
Having an IDL compiler for MingW woul
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 con
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?
If
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 load
Bascily, there should be 3 sorts of APIs exported in WINE.
1.windows apis. These dont change (some may be added or their
implementation improved but the prototypes of an existing call wont change
unless it was wrong in the first place)
2.internal WINE apis. These should be for WINE use only and f
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 but
I heard news that windows 2000 source code was leaked and have seen what
proports to be a filelist.
Dont know if its genuine but for everyones sake I suggest that all people
here completly ignore it (same as I will be doing)
cc-ing WINE list in case its also present in the WINEHQ CVS
this line:
typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW;
should (I believe) be this line:
typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW;
If this is a bug, can someone fix it?
If its not, can someone explain why this construct is prese
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
> Ahhh forget the HeapAlloc stuff. That was my fault. Someone decided in
> a very drain-bamaged way to forward all the Heap* calls to the RtlHeap
> calls in the spec file rather than in the source so anytime we try to
> port Winehq sources for kernel32 that use HeapAlloc I was running in to
> probl
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 should
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 :)
Is such a thing possible or not?
i.e. getting uxtheme, the existing themes and the common controls dll
(various versions of it) working on ROS or Wine fesable?
Has anyone actually tried to get a patent licence from the patent holder
(i.e. Borland) for this?
My argument is that it is not a "Protection Machanisim" as defined by the DMCA.
IANAL but from reading the DMCA information on various places (including
the act itself), the folowing is true:
1.an Access Control Measure is something that prevents unauthorized access
to a Copyrighted work.
2.Ther
> 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
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?
BTW, the header files and libraries used would be licenced under something
like BSD/X11
And the code thats shared between ReactOS and WINE would be LGPL or
something similar.
Currently, we have 3 different projects that are working towards windows
"compatibility".
We have ReactOS
We have WINE
and We have MingW-Runtime and w32Api (refered to as just MingW from now on)
The 3 projects have different goals but the same target. Microsoft Windows
and the Microsoft SDK, DDK
What specificly does this patent cover and what parts of WINE would it affect?
(i.e. which bits of windows, if implemented in WINE, would fall under the
patent?)
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 flights
Say I have a piece of code, x (which is copyright) which always returns the
same output for a given input (e.g. a function that implements a math
formula or a function that retrieves some value from an internal data table
stored in the dll or whatever)
Lets then say that I havent seen this code
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 as
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 but
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?
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
struct GDIHandleBitFields {
unsigned long Index:0:10;
unsigned long Type:10:5;
unsigned long AltType:15:2;
unsigned long Stock:17:1;
unsigned long Unique:18:8;
};
This might help people trying to understand the inner workings of GDI...
Its current as of windo
I see this:
@ varargs sscanf(str str)
in ntdll.spec
but I cant find the defintion behind it.
Also, searching on source.winehq.org doesnt find it either
Thanks for the help, here is the list of what I still need:
advapi32.dll
A_SHAFinal
A_SHAInit
A_SHAUpdate
CancelOverlappedAccess
CloseCodeAuthzLevel
ComputeAccessTokenFromCodeAuthzLevel
ConvertAccessToSecurityDescriptorA
ConvertAccessToSecurityDescriptorW
ConvertSDToStringSDRootDomainA
ConvertSDToS
advapi32.dll
A_SHAFinal
A_SHAInit
A_SHAUpdate
AccessCheckByType
AccessCheckByTypeAndAuditAlarmA
AccessCheckByTypeAndAuditAlarmW
AccessCheckByTypeResultList
AccessCheckByTypeResultListAndAuditAlarmA
AccessCheckByTypeResultListAndAuditAlarmByHandleA
AccessCheckByTypeResultListAndAuditAlarmByHandleW
A
70 matches
Mail list logo
