Imagine an even worse written application :
fptr = GetProcAdress(hDll, "SomeVistaExport");
if(fptr)
Vista = TRUE;
I know at least one application that does it, and this is... wine tests!
Le 13/11/2010 19:41, Colin Finck a écrit :
Ged Murphy wrote:
Usermode should and does report as NT5.2
On 13.11.2010 19:44, Colin Finck wrote:
Sven Barth wrote:
Regarding the anonymous structure: wouldn't this break compatibility
with gcc? (I don't know what features gcc supports ^^)
Anonymous structures are fully supported by GCC when using the flag
-fms-extensions. We have it enabled through
Hi,
GCC is a compiler. CMAKE is a build system we use with... GCC (for the moment).
So no point in the question.
Best regards,
P. Schweitzer
> ...and what about cmake?
> ´cos we are moving from gcc to cmake
>
> On Sat, Nov 13, 2010 at 7:44 PM, Colin Finck wrote:
>
> > Sven Barth wrote:
...and what about cmake?
´cos we are moving from gcc to cmake
On Sat, Nov 13, 2010 at 7:44 PM, Colin Finck wrote:
> Sven Barth wrote:
>
>> Regarding the anonymous structure: wouldn't this break compatibility
>> with gcc? (I don't know what features gcc supports ^^)
>>
>
> Anonymous structur
Sven Barth wrote:
Regarding the anonymous structure: wouldn't this break compatibility
with gcc? (I don't know what features gcc supports ^^)
Anonymous structures are fully supported by GCC when using the flag
-fms-extensions. We have it enabled throughout the whole codebase.
Colin
__
what about just try to make a Windows XP (the most widely desktop OS used
nowadays) clone?
this discussion can only be finished in a bad way for ReactOS IMO
On Sat, Nov 13, 2010 at 7:36 PM, Samuel serapion wrote:
> Doesn't windows use SxS to provide multiple versions of some dlls? I know
> it
Ged Murphy wrote:
Usermode should and does report as NT5.2.
It actually doesn't have a choice as the APIs which you use in usermode
to discover the version (GetVersionEx, VerifyVersionInfo) actually query
hardcoded values stored in the kernel.
Sure, but you don't consider the example I've give
Doesn't windows use SxS to provide multiple versions of some dlls? I know
its not for exacly the same purpose but perhaps coupled with some sort of
app compat wizard we could really set hard version targets... but ofcourse
it would mean building many dlls more than once
On Nov 13, 2010 2:09 PM, "Co
On 13.11.2010 19:22, Colin Finck wrote:
Sven Barth wrote:
Shouldn't it be "_RTL_DRIVE_LETTER_CURDIR" instead of
"RTL_DRIVE_LETTER_CURDIR"?
It doesn't matter if you just define a variable using this structure
like "RTL_DRIVE_LETTER_CURDIR MyVariable;".
It just matters if you somewhere declare
Sven Barth wrote:
Shouldn't it be "_RTL_DRIVE_LETTER_CURDIR" instead of
"RTL_DRIVE_LETTER_CURDIR"?
It doesn't matter if you just define a variable using this structure
like "RTL_DRIVE_LETTER_CURDIR MyVariable;".
It just matters if you somewhere declare it as "struct
RTL_DRIVE_LETTER_CURDIR
You misinterpreted what I said.
I didn't say usermode reports as being Win7, I said it can and should target
features of Win7.
Usermode should and does report as NT5.2.
It actually doesn't have a choice as the APIs which you use in usermode to
discover the version (GetVersionEx, VerifyVersionInfo)
Ged Murphy wrote:
Kernel targets 2k3 (additionally with any newer architecture if possible
/ applicable.
Usermode targets the latest version of Windows.
This means that we always need to ensure that applications properly
detect ReactOS as NT 5.2 all the time and don't expect features of newer
Hello together!
I'm currently poking around in the NDK headers very much and I noted a
small inconsistency in the declaration of one type.
The declaration is the following in include\ndk\rtltypes.h:
source begin
typedef struct RTL_DRIVE_LETTER_CURDIR
{
USHORT Flags;
USHORT
This has always been the official stance back from the day when Thomas
implemented the first usermode Vista API in reactos.
We've had this discussion many times from that moment.
Kernel targets 2k3 (additionally with any newer architecture if possible /
applicable.
Usermode targets the latest vers
Sounds like a plan. And then gradually implement necessary kernel functionality as it is needed.On Sun, 14 Nov 2010 01:18:36 +1100, Jérôme Gardou wrote:
So, for kernel we keep our own importibs, adding exports one after
the other while we implement them, and for user mode dlls we keep
So, for kernel we keep our own importibs, adding exports one after the
other while we implement them, and for user mode dlls we keep win7
compatible ones?
We need an official stance on this matter.
Le 13/11/2010 03:10, Ged Murphy a écrit :
The target is only win2k3 in the kernel. Everything el
Am 13.11.2010 12:31, schrieb Ged Murphy:
> Microsoft already provide similar technology known as virtual dlls.
> It was a technology designed for MinWin.
>
> They split functionality of dlls into ?api sets? These can be seen in
> Win 7 in the system32 dir with the prefix ?api-ms-win-core-- of>-1-
Microsoft already provide similar technology known as virtual dlls.
It was a technology designed for MinWin.
They split functionality of dlls into ‘api sets’ These can be seen in Win 7
in the system32 dir with the prefix ‘api-ms-win-core---1-0.dll’.
WinMin components link against these virtual dl
The only issue here is that we'd have to duplicate a lot of coding effort
from Wine - if we are to use most Wine code then we don't have to bother.
We can just use the existing Wine DLLs as they are at this stage.
IMO if it ain't broke, don't fix it. :)
On Sat, 13 Nov 2010 22:16:11 +1100, Ti
Then let's have a kernelbase.dll, as win7 does.
Le 13/11/2010 12:16, Timo Kreuzer a écrit :
I have thought about the multiple Windows version thing some time ago
and had some ideas.
One idea is to Reorganize the functionality, similar to the way it's
done in Windows 7.
some of the win32 dlls wo
I have thought about the multiple Windows version thing some time ago
and had some ideas.
One idea is to Reorganize the functionality, similar to the way it's
done in Windows 7.
some of the win32 dlls would become wrapper dlls and forwarding to the
actual implementations. These wrapper dlls would
I am also in agreement here. And there are some things I'll admit that NT 5.2 doesn't do as well as NT 6.1 does... like for example lack of UIPI and UAC (may a bird poo on my head such that I do not get shot for saying that) and the ever so old GINA system for example.And of course why not a com
I fully agree with Ged. There is no reason to think "I won't do something a
better way because it's implemented poorly in Win2k3, and ROS's official target
is Win2k3". All what is said applies mainly to the kernel, and ideally in
future our Win32 subssytem should have shim support for compatibil
Wine can do that as they only provide usermode. (we actually allow something
slightly along these lines by allowing the user to decide whether they're
running on a server or workstation. It's an option in one of the cpl
applets)
If you did what Wine do then the user would expect to interface with a
This policy is inconsistent with the fact that we advertise reactos as
win2k3 sp1. Otherwise we should as well provide a config applet to let
the user choose that, as wine does.
Le 13/11/2010 03:10, Ged Murphy a écrit :
The target is only win2k3 in the kernel. Everything else is open to
discus
25 matches
Mail list logo
