Our LoadIcon is broken and can result in badly drawn / ugly icons.
You should use LoadImage instead.
LoadIcon is deprecated anyway, no one should be using it anymore.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of janderwald(a)svn.reactos.org
Sent: 17 September 2008 22:59
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [janderwald] 36295: - Update Status Icon when there is activity - Also update the Taskbar Notification Icon
+ hIcon = NULL;
+ if (pContext->dwInOctets == IfEntry.dwInOctets && pContext->dwOutOctets == IfEntry.dwOutOctets && pContext->Status != 0)
+ {
+ hIcon = LoadIcon(netshell_hInstance, MAKEINTRESOURCE(IDI_NET_IDLE));
+ pContext->Status = 0;
+ }
+ else if (pContext->dwInOctets != IfEntry.dwInOctets && pContext->dwOutOctets !=
In my recent endeavors into porting ReactOS to the amd64 architecture I have
discovered that the the x86_64-pc-mingw32 target uses DWARF debugging
symbols by default.
The reason for this change was very simple, stabs are strictly 32bit. A
stabs record only has 32 bits to represent an address, it represents less
information, was never properly standardized, so gdb is pretty much the only
debugger which can handle gcc stabs in their full glory, and it is larger to
boot. DWARF is better in every aspect. There is no reason to use stabs these
days.
encoded • does i386-mingw32 support DWARF2 ?
NightStrike • the plan is that gcc4.3 will
NightStrike • more specifically, it will also drop support for sjlj
Dwarf 2 Unwind frames for mingw32/cygwin
patch<http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html>
mingw32-gcc4.3 packages are so patched afaics:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304
Right now ReactOS has a tool called rsym that parses stabs and coff symbol
data.
arty • rsym was made to keep compact line number info
Ask yourself:
Could we eliminate an entire build step that is imposed on all ros binaries?
How hard would it be to teach the kernel about DWARF? (If we really wanted
to)
sedwards • wine dbghelp supports pdb too
sedwards • CV, PDB, Stabs and Dwarf
sedwards • as far as I know
Reading Material:
http://dwarfstd.org/dwarf-2.0.0.pdfhttp://dwarfstd.org/Dwarf3.pdf
All these recent umode network commits need to be reverted. Public definitions don't belong in a private header.
As I said in my original commit " It won't build yet as it will rely on a rewrite of the network headers".
When the header rewrites are committed (maybe a week from now) everything will build. It's at this point that people can get involved in getting the new umode architecture working in ros.
Cheers,
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org
Sent: 17 September 2008 04:07
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [cgutman] 36275: - Add ADDRINFOW
Author: cgutman
Date: Tue Sep 16 22:07:15 2008
New Revision: 36275
URL: http://svn.reactos.org/svn/reactos?rev=36275&view=rev
Log:
- Add ADDRINFOW
Modified:
branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h
Modified: branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h
URL: http://svn.reactos.org/svn/reactos/branches/umode-network-branch/dll/win32/…
==============================================================================
--- branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h [iso-8859-1] (original)
+++ branches/umode-network-branch/dll/win32/ws2_32/inc/ws2_32p.h [iso-8859-1] Tue Sep 16 22:07:15 2008
@@ -21,6 +21,18 @@
WsAsyncGetServByPort,
WsAsyncTerminate,
} WSASYNCOPS;
+
+typedef struct _ADDRINFOW
+{
+ INT ai_flags;
+ INT ai_family;
+ INT ai_socktype;
+ INT ai_protocol;
+ SIZE_T ai_addrlen;
+ PWSTR ai_canonname;
+ struct SOCKADDR *ai_addr;
+ struct ADDRINFOW *ai_next;
+} ADDRINFOW, *PADDRINFOW;
typedef struct _WSASYNCBLOCK
{
I would prefer to have a log message saying what was NOT synced too.
On Sep 13, 2008, at 7:52 PM, cwittich(a)svn.reactos.org wrote:
> Author: cwittich
> Date: Sat Sep 13 10:52:50 2008
> New Revision: 36188
>
> URL: http://svn.reactos.org/svn/reactos?rev=36188&view=rev
> Log:
> sync most of rpcrt4 to wine 1.1.4
Hi,
the change done in r36137 on cdfs/fsctl.c appears to me to be wrong. For CDFS, IoCreateDevice should have its 4th parameter set to FILE_DEVICE_CD_ROM_FILE_SYSTEM and not to FILE_DEVICE_DISK_FILE_SYSTEM. For fastfat driver, it's OK.
WBR,
P. Schweitzer
_________________________________________________________________
Installez gratuitement les 20 émôticones Windows Live Messenger les plus fous ! Cliquez ici !
http://www.emoticones-messenger.fr/
On Mon, Sep 8, 2008 at 9:48 AM, <dchapyshev(a)svn.reactos.org> wrote:
> Author: dchapyshev
> Date: Mon Sep 8 08:48:25 2008
> New Revision: 36054
>
> URL: http://svn.reactos.org/svn/reactos?rev=36054&view=rev
> Log:
> - Import pstorec from wine head
Here is a patch from the CrossOver wine that are not in the Winehq
tree. Feel free to fork for a while as no one in winehq has touched
this dll for a while.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
On Sat, Sep 6, 2008 at 5:02 PM, <sginsberg(a)svn.reactos.org> wrote:
> - Make sure we get a Subkey in RegDeleteKeyA/W. Fixes Winetests causing a system crash, but (for now) hides a bug in CM.
Maybe we should throw a DPRINT1 here so we are reminded that the bug
is still there.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Greetings,
I would like to formerly invite the ReactOS community to participate at
the Southern California Linux Expo. The show will be taking place
February 20th - 22nd, 2009 at the Westin LAX in Los Angeles, CA. I am
including both a link to our "Call For dotORG Exhibitors" as well as our
"Call for Papers" if anyone from the ReactOS community is interested in
submitting a talk for consideration.
More information about the show can be found at
http://www.socallinuxexpo.org
Thanks!
Gareth
http://scale7x.socallinuxexpo.org/s7x_cfphttp://scale7x.socallinuxexpo.org/s7x_call_for_dotOrg_exhibitors
--
Gareth J. Greenaway <g(a)socallinuxexpo.org>
Voice - 877-831-2569 x130
Southern California Linux Expo
http://www.socallinuxexpo.org
On Sun, Aug 31, 2008 at 2:07 PM, <janderwald(a)svn.reactos.org> wrote:
> #define REACTOS_STR_ORIGINAL_FILENAME "netshell.dll\0"
> #define REACTOS_STR_PRODUCT_VERSION "5.1.2600.3264\0"
> #define REACTOS_STR_FILE_VERSION "5.1.2600.3264\0"
> +#define REACTOS_STR_COMPANY_NAME "Microsoft Corporation"
Is there an application that actually depends on the string "Microsoft
Corporation" here? If not then you need to remove it otherwise someone
will think your ripping Microsoft's code.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
ntoskrnl/io/iomgr/file.c: In function 'IopCloseFile':
ntoskrnl/io/iomgr/file.c:1407: error: expected expression before '<<' token
ntoskrnl/io/iomgr/file.c:1410: error: expected expression before '==' token
ntoskrnl/io/iomgr/file.c:1413: error: expected expression before '>>' token
mingw32-make: *** [obj-i386/ntoskrnl/io/iomgr/file_ntoskrnl.o] Error 1
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
But, this was reported to me as working: abiword & firefox install,
vmwinst (which exposes vectored handler test) works.
I experienced triple fault on a clean build too, so it's not a random
problem.
How so? People demand explanations about testing techniques Stefan uses.
WBR,
Aleksey Bragin.
On Sep 1, 2008, at 1:58 AM, pschweitzer(a)svn.reactos.org wrote:
> Author: pschweitzer
> Date: Sun Aug 31 16:58:44 2008
> New Revision: 35846
>
> URL: http://svn.reactos.org/svn/reactos?rev=35846&view=rev
> Log:
> Reverted r35812 because of unwanted triple fault bug.
> See issue #3704,3706 for more details.
>
> Modified:
> trunk/reactos/dll/ntdll/dispatch/ (props changed)
> trunk/reactos/dll/ntdll/dispatch/dispatch.c
> trunk/reactos/dll/ntdll/dispatch/i386/dispatch.S
> trunk/reactos/lib/rtl/i386/except.c
> trunk/reactos/lib/rtl/rtlp.h
> trunk/reactos/lib/rtl/vectoreh.c
>
err, sorry. that should be ntddk.h and not winddk.h ;0)
>"Umtypes is only included for user-mode, not for drivers."
>
>ketypes.h imports umtypes.h --
>
>#include <umtypes.h>
>#ifndef NTOS_MODE_USER
>#include <haltypes.h>
>#include <potypes.h>
>#include <ifssupp.h>
>#endif
>
>"Drivers do not import winnt.h"
>they (still) do in ros as winddk.h imports winnt.h...
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
Umtypes is only included for user-mode, not for drivers.
My e-mail was about drivers.
Drivers do not import winnt.h
Drivers import ntifs, wdm and ntddk.
Ntifs, wdm and ntddk are the headers that drivers import.
Not winnt.h.
My e-mail specifically listed those three headers and talked about drivers.
You guys come back saying "it's in winnt.h so it's okay!"
Are you blind, illiterate, or what?
Best regards,
Alex Ionescu
On Sun, Aug 31, 2008 at 10:35 PM, Alex Ionescu <aionescu(a)gmail.com> wrote:
> Umtypes is only included for user-mode, not for drivers.
>
> My e-mail was about drivers.
>
> Drivers do not import winnt.h
>
> Drivers import ntifs, wdm and ntddk.
>
> Ntifs, wdm and ntddk are the headers that drivers import.
>
> Not winnt.h.
>
> My e-mail specifically listed those three headers and talked about drivers.
>
> You guys come back saying "it's in winnt.h so it's okay!"
>
> Are you blind, illiterate, or what?
>
> Best regards,
> Alex Ionescu
>
>
>
> 2008/8/31 Stefan Ginsberg <stefan__100__(a)hotmail.com>:
>> The NDK includes winnt.h through umtypes.h -> windef.h -> winnt.h (MS PSDK's
>> windef.h includes winnt.h too, so I assumed this was correct).
>> If this is wrong then how should it be done?
>>
>>> Date: Sun, 31 Aug 2008 01:00:18 +0200
>>> From: ionucu(a)videotron.ca
>>> To: ros-dev(a)reactos.org
>>> Subject: Re: [ros-dev] [ros-diffs] [sginsberg] 35819: - CACHE_DESCRIPTOR
>>> and PROCESSOR_CACHE_TYPE are public and defined in winnt.h, so no need to
>>> define them in the NDK (the NDK includes winnt.h through windef.h, so this
>>> breaks build)
>>>
>>> Please make sure that these types are available for DRIVERS as well --
>>> otherwise, they belong in the NDK. (Check with WDK
>>> wdm.h/ntddk.h/ntifs.h -- if it's not there, and drivers can access
>>> pointers/structures of this type, it must be in the NDK).
>>>
>>> Also, the NDK does not include winnt.h -- at least it's not supposed
>>> to, unless someone broke it.
>>>
>>> For the future, please make suer to review NDK changes with me, since
>>> I'm still its owner.
>>>
>>> Best regards,
>>> Alex Ionescu
>>>
>>>
>>>
>>> On Sat, Aug 30, 2008 at 11:34 PM, <sginsberg(a)svn.reactos.org> wrote:
>>> > Author: sginsberg
>>> > Date: Sat Aug 30 16:34:56 2008
>>> > New Revision: 35819
>>> >
>>> > URL: http://svn.reactos.org/svn/reactos?rev=35819&view=rev
>>> > Log:
>>> > - CACHE_DESCRIPTOR and PROCESSOR_CACHE_TYPE are public and defined in
>>> > winnt.h, so no need to define them in the NDK (the NDK includes winnt.h
>>> > through windef.h, so this breaks build)
>>> >
>>> > Modified:
>>> > trunk/reactos/include/ndk/ketypes.h
>>> >
>>> > Modified: trunk/reactos/include/ndk/ketypes.h
>>> > URL:
>>> > http://svn.reactos.org/svn/reactos/trunk/reactos/include/ndk/ketypes.h?rev=…
>>> >
>>> > ==============================================================================
>>> > --- trunk/reactos/include/ndk/ketypes.h [iso-8859-1] (original)
>>> > +++ trunk/reactos/include/ndk/ketypes.h [iso-8859-1] Sat Aug 30 16:34:56
>>> > 2008
>>> > @@ -542,17 +542,6 @@
>>> > } KAPC_ENVIRONMENT;
>>> >
>>> > //
>>> > -// CPU Cache Types
>>> > -//
>>> > -typedef enum _PROCESSOR_CACHE_TYPE
>>> > -{
>>> > - CacheUnified,
>>> > - CacheInstruction,
>>> > - CacheData,
>>> > - CacheTrace,
>>> > -} PROCESSOR_CACHE_TYPE;
>>> > -
>>> > -//
>>> > // PRCB DPC Data
>>> > //
>>> > typedef struct _KDPC_DATA
>>> > @@ -571,18 +560,6 @@
>>> > struct _GENERAL_LOOKASIDE *P;
>>> > struct _GENERAL_LOOKASIDE *L;
>>> > } PP_LOOKASIDE_LIST, *PPP_LOOKASIDE_LIST;
>>> > -
>>> > -//
>>> > -// CPU Cache Descriptor
>>> > -//
>>> > -typedef struct _CACHE_DESCRIPTOR
>>> > -{
>>> > - UCHAR Level;
>>> > - UCHAR Associativity;
>>> > - USHORT LineSize;
>>> > - ULONG Size;
>>> > - PROCESSOR_CACHE_TYPE Type;
>>> > -} CACHE_DESCRIPTOR, *PCACHE_DESCRIPTOR;
>>> >
>>> > //
>>> > // Architectural Types
>>> >
>>> >
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev(a)reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>> ________________________________
>> Connect to the next generation of MSN Messenger Get it now!
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
Please make sure that these types are available for DRIVERS as well --
otherwise, they belong in the NDK. (Check with WDK
wdm.h/ntddk.h/ntifs.h -- if it's not there, and drivers can access
pointers/structures of this type, it must be in the NDK).
Also, the NDK does not include winnt.h -- at least it's not supposed
to, unless someone broke it.
For the future, please make suer to review NDK changes with me, since
I'm still its owner.
Best regards,
Alex Ionescu
On Sat, Aug 30, 2008 at 11:34 PM, <sginsberg(a)svn.reactos.org> wrote:
> Author: sginsberg
> Date: Sat Aug 30 16:34:56 2008
> New Revision: 35819
>
> URL: http://svn.reactos.org/svn/reactos?rev=35819&view=rev
> Log:
> - CACHE_DESCRIPTOR and PROCESSOR_CACHE_TYPE are public and defined in winnt.h, so no need to define them in the NDK (the NDK includes winnt.h through windef.h, so this breaks build)
>
> Modified:
> trunk/reactos/include/ndk/ketypes.h
>
> Modified: trunk/reactos/include/ndk/ketypes.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ndk/ketypes.h?rev=…
> ==============================================================================
> --- trunk/reactos/include/ndk/ketypes.h [iso-8859-1] (original)
> +++ trunk/reactos/include/ndk/ketypes.h [iso-8859-1] Sat Aug 30 16:34:56 2008
> @@ -542,17 +542,6 @@
> } KAPC_ENVIRONMENT;
>
> //
> -// CPU Cache Types
> -//
> -typedef enum _PROCESSOR_CACHE_TYPE
> -{
> - CacheUnified,
> - CacheInstruction,
> - CacheData,
> - CacheTrace,
> -} PROCESSOR_CACHE_TYPE;
> -
> -//
> // PRCB DPC Data
> //
> typedef struct _KDPC_DATA
> @@ -571,18 +560,6 @@
> struct _GENERAL_LOOKASIDE *P;
> struct _GENERAL_LOOKASIDE *L;
> } PP_LOOKASIDE_LIST, *PPP_LOOKASIDE_LIST;
> -
> -//
> -// CPU Cache Descriptor
> -//
> -typedef struct _CACHE_DESCRIPTOR
> -{
> - UCHAR Level;
> - UCHAR Associativity;
> - USHORT LineSize;
> - ULONG Size;
> - PROCESSOR_CACHE_TYPE Type;
> -} CACHE_DESCRIPTOR, *PCACHE_DESCRIPTOR;
>
> //
> // Architectural Types
>
>
pschweitzer(a)svn.reactos.org wrote:
> +DWORD WINAPI sfc_8()
>
I hope you guys realize that sfc_8 () compiled as C is different from
what it'd be when compiled as C++. In C this means that it is a cdecl
function with variable arguments (I guess WINAPI overrides cdecl, but
still). If it is compiled as C++, it means the same as sfc_8 (void). So
better have a void argument list.
Thomas
sginsberg(a)svn.reactos.org a écrit :
> Author: sginsberg
> Date: Sun Aug 24 10:48:05 2008
> New Revision: 35600
>
> URL: http://svn.reactos.org/svn/reactos?rev=35600&view=rev
> Log:
> - Remove KEBUGCHECK and KEBUGCHECKEX macros
> - Replace "KeBugCheck(0)" by ASSERT(FALSE)
> - Replace deprecated "CPRINT" by DRINT1
>
You probably understand that KEBUGCHECK(0) is *NOT* the same as
ASSERT(FALSE)
ASSERT(FALSE) is valid only in debug mode, and lets the code continue in
release mode.
KEBUGCHECK stops the execution also in release mode.
For example, in ntoskrnl/dbgk/dbgkobj.c, code now continues even if
DbgkpQueueMessage failed. Are you sure it is safe to continue in that case?
(same question applies for other locations)
Hervé
In the kernel, stdcall IoCallDriver is macroed to the fastcall IofCallDriver. However, for clarification I think that IoCallDriver should be used, and this is what we do everywhere else.
>Why this?
>> ======================================================================
>> --- trunk/reactos/ntoskrnl/io/iomgr/iofunc.c [iso-8859-1] (original)
>> +++ trunk/reactos/ntoskrnl/io/iomgr/iofunc.c [iso-8859-1] Sat Aug 23
>> 11:30:14 2008
>> @@ -682,7 +682,7 @@
>> StackPtr->FileObject = FileObject;
>>
>> /* Call the Driver */
>> - return IofCallDriver(DeviceObject, Irp);
>> + return IoCallDriver(DeviceObject, Irp);
>> }
>>
>> /*
>> @@ -732,7 +732,7 @@
>> StackPtr->FileObject = FileObject;
>>
>> /* Call the Driver */
>> - return IofCallDriver(DeviceObject, Irp);
>> + return IoCallDriver(DeviceObject, Irp);
>> }
>>
>>
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
--- Please, please, don't think I'm trying to say "revert this!" ---
There are dozens (if not more) places in the kernel where such checks
could/should be made. I believe the more correct approach instead of
adding them to every function, is to use a similar framework to
Microsoft's Driver Verifier, where such functions are hooked and
wrapped through similar verifications.
I'm not saying this particular assert should be removed, I'm just
letting people know that if there's going to be major work on this --
there's a better way.
Just my 2c.
On 23-Aug-08, at 4:04 PM, arty(a)svn.reactos.org wrote:
> Author: arty
> Date: Sat Aug 23 18:04:15 2008
> New Revision: 35581
>
> URL: http://svn.reactos.org/svn/reactos?rev=35581&view=rev
> Log:
> Catch failure to release the cancel spinlock. Would've spotted my
> error in
> tcpip.sys.
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/irp.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/irp.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/irp.c?re…
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/irp.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/irp.c [iso-8859-1] Sat Aug 23
> 18:04:15 2008
> @@ -970,12 +970,14 @@
> IoCancelIrp(IN PIRP Irp)
> {
> KIRQL OldIrql;
> + KIRQL IrqlAtEntry;
> PDRIVER_CANCEL CancelRoutine;
> IOTRACE(IO_IRP_DEBUG,
> "%s - Canceling IRP %p\n",
> __FUNCTION__,
> Irp);
> ASSERT(Irp->Type == IO_TYPE_IRP);
> + IrqlAtEntry = KeGetCurrentIrql();
>
> /* Acquire the cancel lock and cancel the IRP */
> IoAcquireCancelSpinLock(&OldIrql);
> @@ -999,6 +1001,7 @@
> /* Set the cancel IRQL And call the routine */
> Irp->CancelIrql = OldIrql;
> CancelRoutine(IoGetCurrentIrpStackLocation(Irp)-
> >DeviceObject, Irp);
> + ASSERT(IrqlAtEntry == KeGetCurrentIrql());
> return TRUE;
> }
>
>
Best regards,
Alex Ionescu
Feel free to open a bug.
----- Message d'origine ----
De : Olaf Siejka <caemyr(a)gmail.com>
À : ros-dev(a)reactos.org
Envoyé le : Jeudi, 21 Août 2008, 22h47mn 20s
Objet : Re: [ros-dev] Ros-dev Digest, Vol 48, Issue 14
Not to mention that makex is not 100% functional, for example i cannot perform makex depends or even makex bootcd on a clean tree. I have to first do make depends, then makex bootcd.
2008/8/21 <ros-dev-request(a)reactos.org>
Send Ros-dev mailing list submissions to
ros-dev(a)reactos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.reactos.org/mailman/listinfo/ros-dev
or, via email, send a message with subject or body 'help' to
ros-dev-request(a)reactos.org
You can reach the person managing the list at
ros-dev-owner(a)reactos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ros-dev digest..."
Today's Topics:
1. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (gedmurphy)
2. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (Timo Kreuzer)
3. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (Colin Finck)
4. Has anyone given any thought to coding so that the OS can use
the GPU (Matthew Therault)
5. Re: Has anyone given any thought to coding so that the OS can
use the GPU (Steven Edwards)
6. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (Aleksey Bragin)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Aug 2008 12:59:42 +0100
From: "gedmurphy" <gedmurphy(a)gmail.com>
Subject: Re: [ros-dev] [ros-diffs] [dreimer] 35473: make automatically
behaves like makex when there is more then one CPU Core now. makex
kept for now to keep compatible.
To: <ros-dev(a)reactos.org>
Message-ID: <000f01c902bc$3ea137f0$bbe3a7d0$@com>
Content-Type: text/plain; charset="utf-8"
I don't want make to consume both CPU's.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dreimer(a)svn.reactos.org
Sent: 20 August 2008 10:10
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dreimer] 35473: make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Author: dreimer
Date: Wed Aug 20 04:10:07 2008
New Revision: 35473
URL: http://svn.reactos.org/svn/reactos?rev=35473&view=rev
Log:
make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Modified:
trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
Not to mention that makex is not 100% functional, for example i cannot
perform makex depends or even makex bootcd on a clean tree. I have to first
do make depends, then makex bootcd.
2008/8/21 <ros-dev-request(a)reactos.org>
> Send Ros-dev mailing list submissions to
> ros-dev(a)reactos.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.reactos.org/mailman/listinfo/ros-dev
> or, via email, send a message with subject or body 'help' to
> ros-dev-request(a)reactos.org
>
> You can reach the person managing the list at
> ros-dev-owner(a)reactos.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ros-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (gedmurphy)
> 2. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (Timo Kreuzer)
> 3. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (Colin Finck)
> 4. Has anyone given any thought to coding so that the OS can use
> the GPU (Matthew Therault)
> 5. Re: Has anyone given any thought to coding so that the OS can
> use the GPU (Steven Edwards)
> 6. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (Aleksey Bragin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 Aug 2008 12:59:42 +0100
> From: "gedmurphy" <gedmurphy(a)gmail.com>
> Subject: Re: [ros-dev] [ros-diffs] [dreimer] 35473: make automatically
> behaves like makex when there is more then one CPU Core now.
> makex
> kept for now to keep compatible.
> To: <ros-dev(a)reactos.org>
> Message-ID: <000f01c902bc$3ea137f0$bbe3a7d0$@com>
> Content-Type: text/plain; charset="utf-8"
>
> I don't want make to consume both CPU's.
>
> Ged.
>
> -----Original Message-----
> From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org]
> On Behalf Of dreimer(a)svn.reactos.org
> Sent: 20 August 2008 10:10
> To: ros-diffs(a)reactos.org
> Subject: [ros-diffs] [dreimer] 35473: make automatically behaves like makex
> when there is more then one CPU Core now. makex kept for now to keep
> compatible.
>
> Author: dreimer
> Date: Wed Aug 20 04:10:07 2008
> New Revision: 35473
>
> URL: http://svn.reactos.org/svn/reactos?rev=35473&view=rev
> Log:
> make automatically behaves like makex when there is more then one CPU Core
> now. makex kept for now to keep compatible.
>
> Modified:
> trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
> trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
I don't want make to consume both CPU's.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dreimer(a)svn.reactos.org
Sent: 20 August 2008 10:10
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dreimer] 35473: make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Author: dreimer
Date: Wed Aug 20 04:10:07 2008
New Revision: 35473
URL: http://svn.reactos.org/svn/reactos?rev=35473&view=rev
Log:
make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Modified:
trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
Modified: trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Root/Bui…
==============================================================================
--- trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd [iso-8859-1] (original)
+++ trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd [iso-8859-1] Wed Aug 20 04:10:07 2008
@@ -103,11 +103,20 @@
)
::
+:: Get the number of CPUs in the system so we know how many jobs to execute.
+:: To modify the number used alter the options used with cpucount:
+:: No Option - Number of CPUs.
+:: -x1 - Number of CPUs, plus 1.
+:: -x2 - Number of CPUs, doubled.
+:: -a - Determine the cpu count based on the inherited process affinity mask.
+::
+for /f "usebackq" %%i in (`"%_ROSBE_BASEDIR%\Tools\cpucount.exe" -x1`) do set CPUCOUNT=%%i
+::
:: Check if we are using -j or not.
::
-if "%1" == "multi" (
- if not "%2" == "" (
- title 'makex %2' parallel build started: %TIMERAW%
+if %CPUCOUNT% GTR 2 (
+ if not "%1" == "" (
+ title 'makex %1' parallel build started: %TIMERAW%
) else (
title 'makex' parallel build started: %TIMERAW%
)
@@ -139,27 +148,17 @@
goto :EOF
:BUILDMULTI
- ::
- :: Get the number of CPUs in the system so we know how many jobs to execute.
- :: To modify the number used alter the options used with cpucount:
- :: No Option - Number of CPUs.
- :: -x1 - Number of CPUs, plus 1.
- :: -x2 - Number of CPUs, doubled.
- :: -a - Determine the cpu count based on the inherited process affinity mask.
- ::
- for /f "usebackq" %%i in (`"%_ROSBE_BASEDIR%\Tools\cpucount.exe" -x1`) do set CPUCOUNT=%%i
-
if %_ROSBE_SHOWTIME% == 1 (
if %_ROSBE_WRITELOG% == 1 (
- "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
+ "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %* 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
) else (
- "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9
+ "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %*
)
) else (
if %_ROSBE_WRITELOG% == 1 (
- "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
+ "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %* 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
) else (
- "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9
+ "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %*
)
)
goto :EOF
Modified: trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Root/Ros…
==============================================================================
--- trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac [iso-8859-1] (original)
+++ trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac [iso-8859-1] Wed Aug 20 04:10:07 2008
@@ -7,7 +7,7 @@
ENV = set
HELP = "%_ROSBE_BASEDIR%\Help.cmd" $*
MAKE = "%_ROSBE_BASEDIR%\Build.cmd" $*
-MAKEX = "%_ROSBE_BASEDIR%\Build.cmd" multi $*
+MAKEX = "%_ROSBE_BASEDIR%\Build.cmd" $*
RADDR2LINE = "%_ROSBE_BASEDIR%\reladdr2line.cmd" $*
RENV = for /f "usebackq tokens=*" %i in (`set _ROSBE_`) do @echo %i
SCUT = "%_ROSBE_BASEDIR%\scut.cmd" $*
Just a random thought wondering if anyone else has thought about it. They
are making great strides into how the GPU can now be used as a processor.
--
Two men walk into a bar....... Third one ducks....
Think about it, it will come to you. :P
On Thu, Aug 14, 2008 at 5:35 PM, <tkreuzer(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=35346&view=rev
> Log:
> PE symbol dumper. It's not finished, functions don't work and the type output doesn't always look 100% correct. But it does it's job. You need dbghelp.dll and symsrv.dll from windbg.
You could also import winedump.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Please merge this change to trunk too, if NDK author does not object.
WBR,
Aleksey Bragin.
On Aug 16, 2008, at 3:40 AM, tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Fri Aug 15 18:40:42 2008
> New Revision: 35359
>
> URL: http://svn.reactos.org/svn/reactos?rev=35359&view=rev
> Log:
> The TEB member is called ClientID not Cid on all Windows versions I
> could check (XP, 2k3, vista).
I'd rather pester you to finish work on your SEH paper and translation of
parts of your thesis.
On Fri, Aug 15, 2008 at 12:31 AM, KJK::Hyperion <hackbunny(a)reactos.org>wrote:
> Zachary Gorden ha scritto:
> > However, there may be developers who do not wish to maintain
> > their own blog or want to keep their ROS bloggings separate and want to
> > make use of the system integrated in the CMS. Any thoughts?
>
> Do both (aggregator AND blog platform). Then pester me to blog
> _______________________________________________
> Ros-web mailing list
> Ros-web(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-web
>
Sending this to both mailing lists as I don't know how many developers are
actually subscribed to the web list.
For some time now, the blog on the ReactOS site hasn't been used. When I
asked if Aleksey was against putting up a "preview" of sorts on the front
page in an attempt to revive it, some of the developers such as Ged pointed
out no one really used it anymore and a few already had their own blogs and
didn't want to maintain two. Ged has already moved to remove the link in
the quick menu, though no formal decision has been made yet (the link is
still there until a refresh occurs, though we might end up restoring it
anyways).
I personally believe the blog could be quite useful, even if its current
form changes. An alternative would be an aggregation of the RSS feeds from
the blogs maintained by each ROS developer, assuming they have a blog.
However, there may be developers who do not wish to maintain their own blog
or want to keep their ROS bloggings separate and want to make use of the
system integrated in the CMS. Any thoughts?
else
{
/* System Thread */
Thread->StartAddress = StartRoutine;
PspSetCrossThreadFlag(Thread, CT_SYSTEM_THREAD_BIT);
Looks good to me.
And CT_SYSTEM_THREAD_BIT is defined to 0x10 which is correct:
union
{
struct
{
ULONG Terminated:1;
#if (NTDDI_VERSION >= NTDDI_LONGHORN)
ULONG ThreadInserted:1;
#else
ULONG DeadThread:1;
#endif
ULONG HideFromDebugger:1;
ULONG ActiveImpersonationInfo:1;
ULONG SystemThread:1;
so your patch was correct and should be re-applied.
On 12-Aug-08, at 3:22 PM, sginsberg(a)svn.reactos.org wrote:
> Author: sginsberg
> Date: Tue Aug 12 17:22:51 2008
> New Revision: 35294
>
> URL: http://svn.reactos.org/svn/reactos?rev=35294&view=rev
> Log:
> - Temporarily revert my last change. We don't set the SystemThread
> flag appropriately and it is always zero
>
> Modified:
> trunk/reactos/ntoskrnl/ps/kill.c
>
> Modified: trunk/reactos/ntoskrnl/ps/kill.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/kill.c?rev=352…
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] Tue Aug 12
> 17:22:51 2008
> @@ -1086,7 +1086,7 @@
> PETHREAD Thread = PsGetCurrentThread();
>
> /* Make sure this is a system thread */
> - if (!Thread->SystemThread) return STATUS_INVALID_PARAMETER;
> + if (Thread->SystemThread) return STATUS_INVALID_PARAMETER;
>
> /* Terminate it for real */
> return PspTerminateThreadByPointer(Thread, ExitStatus, TRUE);
>
Best regards,
Alex Ionescu
Timo Kreuzer wrote:
> And when I have already started moaning about this kind of stuff... what
> about the arm guys? They are so secret they can't even make their
> changelog themselfs? Why that? And why are they so secret that noone
> knows? I mean we keep demanding real name and email from everyone
> creating a patch, yet a bunch of people have direct commit access and
> they keep hiding their names? What reasons are there
I thought it was common knowledge already that Alex is the (only) arm
"guys". Isn't it more than obvious? Very same coding style, knowledge,
comments, rants, ... How stupid does one have to be not to realize the
connection? Prove me otherwise... And since you're complaining about not
being open, why do you only post this to the private list?
Thomas
MS defines most of those in the wdk, if NO_INTERLOCKED_INTRINSICS is not defined
> +#define InterlockedDecrement _InterlockedDecrement
> +#define InterlockedDecrement16 _InterlockedDecrement16
> +#define InterlockedIncrement _InterlockedIncrement
> +#define InterlockedIncrement16 _InterlockedIncrement16
> +#define InterlockedCompareExchange _InterlockedCompareExchange
> +#define InterlockedCompareExchange16 _InterlockedCompareExchange16
> +#define InterlockedCompareExchange64 _InterlockedCompareExchange64
> +#define InterlockedExchange _InterlockedExchange
> +#define InterlockedExchangeAdd _InterlockedExchangeAdd
>
On Tue, Aug 5, 2008 at 10:45 AM, <dchapyshev(a)svn.reactos.org> wrote:
> +#include "../crypt/crypt.h"
Minor nitpicking, Do you mind fixing this?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
On Sat, Aug 2, 2008 at 6:33 PM, <mkupfer(a)svn.reactos.org> wrote:
> Author: mkupfer
> Date: Sat Aug 2 17:33:58 2008
> New Revision: 35050
>
> URL: http://svn.reactos.org/svn/reactos?rev=35050&view=rev
> Log:
> revert to 35046, sorry for mistake
Ignore my message, I did not see where you fixed it.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
On Sat, Aug 2, 2008 at 5:57 PM, <mkupfer(a)svn.reactos.org> wrote:
> Author: mkupfer
> Date: Sat Aug 2 16:57:53 2008
> New Revision: 35047
>
> URL: http://svn.reactos.org/svn/reactos?rev=35047&view=rev
> Log:
> Reorganize shdocvw:
> - Moved and renamed language resource files into created 'lang' directory.
> - Outdated shdocvw_ros.diff removed.
This is wrong, shdocvw will keep being synced as soon as the widl bug
is fixed so the resources should stay in the dll root to save whoever
is doing the sync the trouble of having to move resources around.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I've written a shell to use with ReactOS' KDBG that gives a more accurate
view of what's going on than other methods available to us (it automatically
grabs the module list and loads source files as appropriate, shows locals etc)
It's not complete yet, and I'm hoping that others will want to participate in
working on it. Therefore, I'm asking those with C# experience on windows who
want to get involved to lend a hand in adding the remaining features:
- abstract pipe implementation for serial ports and windows named pipes
- managing breakpoints
- type decoding and struct display using the info available from dbghelp
- thread and process listing and focus
- a 'watch' window and watchpoints
- clipboard interaction
- annontated disassembly
- general features (bugzilla reporting, automatic interaction with rospaste)
To work on this, you don't need to be a wizard, just familiar with windows
forms development in C# and willing to learn a thing or two along the way,
along with a vm to intstall reactos in and beat up on :-)
Some day we'll have everything working with windows style kernel debugging,
but until then I feel that a superior stopgap is valuable.
--
art yerkes <ayerkes(a)speakeasy.net>
Alex wrote:
>It looks like a guarded mutex is being acquired at DPC level. That's
>pretty bad.
Well, at least it's redundant and useless. :-)
>Pushlocks shouldn't be acquired at DPC level either
Indeed. If "you" are at DPC level, you have but one synchronization to
care about - SMP (i.e. CPU<->CPU).
>, but there's no
>ASSERTs in the pushlock code that check for that.
An oversight that should be fixed, I'm sure (even if it happened to
slow down the system by a whole order of magnitude, which it won't).
>MMProbeAndLockPages should never be called for paged pool addreses
>while at DPC level,
Should MmProbeAndLock ever be called at IRQL above APC level? I mean,
what if the probing fails? Should the paging executive somehow preempt
this call and page in the missing pages (or should it simply throw a
"page not present" exception - not too great to do at DPC level I'd
say)?
>which means the driver probably called it for a
>non-paged pool address.
If my previous suspicion is correct, I build on that and suspect this
is an error in itself. The ProbeAndLock call should be done at APC
level (though I may be completely wrong, but do read my finishing
line).
>In that case, the whole loop about checking if the page is present
and
>then faulting it in is irrelevant, and won't happen.
Right. Page fault at DPC level == Bad Move(tm).
--
Mike
Hi ARMs,
Doing a good job BTW~
Thanks,
James
(ntoskrnl/kd/kdio.c:191) -----------------------------------------------------
(ntoskrnl/kd/kdio.c:192) ReactOS 0.4-SVN (Build 20080728-r34871)
(ntoskrnl/kd/kdio.c:193) Command Line: DEBUG DEBUGPORT=COM1
BUADRATE=115200 SOS
(ntoskrnl/kd/kdio.c:194) ARC Paths:
multi(0)disk(0)rdisk(0)partition(1) \ multi(0)disk(0)rdisk(0)parti
tion(1) \ReactOS\
Used memory 1015348Kb
(ntoskrnl/mm/mminit.c:295) Start End Type
(ntoskrnl/mm/mminit.c:296) 0x80000000 - 0x80800000 Undefined region
(ntoskrnl/mm/mminit.c:299) 0x80800000 - 0x80E00000 FreeLDR Kernel
mapping region
(ntoskrnl/mm/mminit.c:302) 0x80E00000 - 0x815C0000 PFN Database region
(ntoskrnl/mm/mminit.c:309) 0x815C0000 - 0x879C0000 Non paged pool region
(ntoskrnl/mm/mminit.c:312) 0x879C0000 - 0x8DDC0000 Paged pool region
(ntoskrnl/ke/i386/kiinit.c:47) Large Page support detected but not yet
taken advantage of!
WARNING: KdDebuggerInitialize1 at drivers/base/kdcom/i386/kdbg.c:489
is UNIMPLEMENTED!
WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is
UNIMPLEMENTED!
WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is
UNIMPLEMENTED!
(ntoskrnl/io/iomgr/driver.c:1356) '\Driver\BUSLOGIC' initialization
failed, status (0xc00000c0)
(ntoskrnl/io/iomgr/driver.c:1356) '\Driver\Floppy' initialization
failed, status (0xc000000e)
Assertion 'KeGetCurrentIrql()<=(1)' failed at ntoskrnl/ke/gmutex.c line 201
Entered debugger on embedded INT3 at 0x0008:0x808a8262.
kdb:> bt
Eip:
<NTOSKRNL.EXE:a8263 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:a027 (ntoskrnl/ke/gmutex.c:201 (@KeAcquireGuardedMutex@4))>
<NTOSKRNL.EXE:6d3a2 (ntoskrnl/include/internal/mm.h:1556
(MmProbeAndLockPages@12))>
<NTOSKRNL.EXE:4f079 (ntoskrnl/io/iomgr/irp.c:694
(IoBuildAsynchronousFsdRequest@24))>
<SCSIPORT.SYS:4671 (drivers/storage/scsiport/scsiport.c:3959
(ScsiPortDpcForIsr@16))>
<NTOSKRNL.EXE:823a (ntoskrnl/ke/dpc.c:474 (@KiRetireDpcList@4))>
<NTOSKRNL.EXE:9fc59 (ntoskrnl/ke/i386/ctxswitch.S:691 (@KiIdleLoop@0))>
<00000000>
kdb:>
Hi,
I've been attempting to sync some of the Wine dlls, namely the IE
support dlls and have run in to a bit of a problem which I think is a
bug in ReactOS widl. It seems that the import keyword is not working.
When trying to build shdocvw.dll it creates a shdocvw_v1.tlb based on
shdocvw_v1.idl which imports exdisp.idl from the SDK which in turn
does an import ("stdole2.tlb")
As you can see from the output below
sedwards@mini-gimli:~/source/reactos$ make shdocvw
[WIDL] obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb
error: Could not open importlib stdole2.tlb.
mingw32-make: *** [obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb] Error 2
Total Build Time: 00:00:02
Notice the . at the end of stdole2.tlb? I've tried just renaming the
typelib and putting it in several intermediate folders to no effect.
If any WIDL Guru can help please find the attached patch which
contains an updated shdocvw.rbuild
Thanks
Steven
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Yesterday I was playing around with the test suite in HEAD when I moved onto
kernel32.
It was, without wanting to sound too harsh, a bit of a disgrace, with large
failures throughout the whole test range.
I suggest a hacking day on it using the test suite, a joint effort to bring
this core lib back into line. Perhaps with some emphasis on trying to make
it fun.
Whoever gets the most fixes is crowned 'king ding-a-ling' and holds the
title until the next one, opening the road up to days on ntdll, user32,
gdi32 and crt?
Ged.
Hi,
When installing Java or anything with java it hangs and just sit there
running. It could be OOo 2.4 or installing java, does not mater, I
just left the box running all night and just sits there, still
installing..
This bug fault right after I restarted. Is it waiting on a lock?
Assertion 'WaitBlock->Signaled' failed at ntoskrnl/ex/pushlock.c line 599
Entered debugger on embedded INT3 at 0x0008:0x808ad242.
kdb:> bt
Eip:
<NTOSKRNL.EXE:ad243 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:2da24 (ntoskrnl/ex/pushlock.c:599
(@ExfAcquirePushLockExclusive@4))>
<NTOSKRNL.EXE:6eb00 (ntoskrnl/include/internal/ex.h:715
(MiProtectVirtualMemory@20))>
<NTOSKRNL.EXE:6fdbf (ntoskrnl/mm/virtual.c:927 (NtProtectVirtualMemory@20))>
<NTOSKRNL.EXE:979ca (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5e1a> ntdll/main/i386/dispatch.S:297 (KiFastSystemCallRet@0)
<kernel32.dll:e0ce> kernel32/mem/virtual.c:127 (VirtualProtect@16)
<jvm.dll:149b27>
kdb:>
Hi all,
I'm working on first stage gui setup.
During the development i reviewed the base/setup directory and the different
modules. I suggest following changes:
Now:
reactos.exe: atm greeting only with disabled first stage setup dialogs
setup.exe: switcher for 2nd stage setup (syssetup) or livecd
usetup.exe: textmode 1st stage setup
vmwinst.exe: don't know exactly, vm-ware driver installation
welcome.exe: nice welcome dialog without real functions
Future:
setup.exe: switcher for 1st stage gui setup, 2nd stage setup, livecd and
welcome dialog switched by command line arguments
"setup.exe" -> welcome dialog
"setup.exe -mini" -> livecd
"setup.exe -newsetup1" -> 1st stage gui setup
"setup.exe -newsetup2" -> 2nd stage (gui) setup
usetup.exe: textmode 1st-stage-setup
vmwinst.exe: keeps unchangend
reactos.exe, welcome.exe: removed
Are there any objections to go this way? If not, so i will change this soon.
Matthias
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
On Tue, Jul 22, 2008 at 9:56 AM, Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote:
> It'sToo bad the header is not in an include directory...
Maybe it should go in the NDK then.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
> De : Steven Edwards <winehacker(a)gmail.com>
> À : ros-dev(a)reactos.org
> Envoyé le : Mardi, 22 Juillet 2008, 11h49mn 04s
> Objet : Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 34655: - Build vfatfs instead of CDFS. - Load vfatfs instead of CDFS. - Implement code in the ramdisk driver to handle both ISO and FAT ramdisks. Don't know what the big deal with support ISO ramdisks was supposed to
>
> On Tue, Jul 22, 2008 at 5:42 AM, Steven Edwards wrote:
> > On Tue, Jul 22, 2008 at 1:31 AM, wrote:
> >> #include
> >> +#include "../../../filesystems/fs_rec/fs_rec.h"
> >
> > This can cause problems with parallel makes.
>
> This is what I get for commenting at 5 am...I thought you were
> including another .c file directly. ignore the part about parallel
> makes. But do try to avoid referencing the header like this. Just set
> an include path in the rbuild file and spare my eyes the horror of the
> directory traversal.
>
> --
> Steven Edwards
>
It'sToo bad the header is not in an include directory...
Kind regards,
Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net
On Tue, Jul 22, 2008 at 1:31 AM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> #include <reactos/drivers/ntddrdsk.h>
> +#include "../../../filesystems/fs_rec/fs_rec.h"
This can cause problems with parallel makes.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Indeed, that's not conform to EULA that says: "You may not distribute
Distributable Code to run on a platform other than the Windows platform;".
Moreover, CDFS driver ISN'T listed as a "Distributable Code".
Please revert to avoid any problems.
P. Schweitzer
--------------------------------------------------
From: "Steven Edwards" <winehacker(a)gmail.com>
Sent: Monday, July 21, 2008 12:21 AM
To: <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 34615: - Add new
CDFSdriver. - Does not compile.
> On Sun, Jul 20, 2008 at 3:52 PM, <ros-arm-bringup(a)svn.reactos.org> wrote:
>> URL: http://svn.reactos.org/svn/reactos?rev=34615&view=rev
>> Log:
>> - Add new CDFS driver.
>> - Does not compile.
>
> Ehem...as far as I understand the EULA (unless its changed) you cannot
> use the WDK references drivers for a non-windows OS. Please revert
> this and write you own.
>
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
On Sun, Jul 20, 2008 at 3:52 PM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=34615&view=rev
> Log:
> - Add new CDFS driver.
> - Does not compile.
Ehem...as far as I understand the EULA (unless its changed) you cannot
use the WDK references drivers for a non-windows OS. Please revert
this and write you own.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
after several commits that leads in broken inf-files (last one 34598 by
spetreolle), I invite to take care about following things:
1. The inf files are in UTF-16LE a.k.a. UCS-2LE.
2. All lines ends with CRLF (a single one, no other combination).
3. The files have to start with a bom (byte order mark).
4. There are no more boms allowed anywhere in the file.
Please modify that files _very_ carefully, because we can't check changes via
diff, due to the lack of utf-16 support in svn.
Matthias
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
On Sun, Jul 20, 2008 at 12:40 AM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> - We end up crashing in CcRosTryToInitialzeFileCache because there is no SectionObjectPointer, and it is assumed this always exists.
Ninjas! I don't know if this is related but would it be possible to
switch to doing development on NoCC in case you guys run in to more
problems like these? I don't know if it would help but I assume your
going to run in to more problems with the current Cc and you might be
able to save a lot of trouble later on.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi!
A show is coming up and we need to look good. Haiku looks good and it
has networtking and draws objects very well. Please check our drawing
with test apps and look at networking and see where we are on hardware
support. I know there are bugs maybe by August 4th we can get back
some basic networking with hardware. PCI n2k? or FET?
KPANIC!
James
Maybe it's worth adding these tests to msvcrt test suite and submit
to Wine?
WBR,
Aleksey Bragin.
On Jul 17, 2008, at 2:08 AM, cfinck(a)svn.reactos.org wrote:
> Author: cfinck
> Date: Wed Jul 16 17:08:58 2008
> New Revision: 34558
>
> URL: http://svn.reactos.org/svn/reactos?rev=34558&view=rev
> Log:
> Commit my test suite I used for verifying the behaviours of wctomb,
> wcstombs and WideCharToMultiByte and writing the reimplementations
> for ReactOS on request of Stefan
Hi,
Does "make install" work for you by any chance?
I get this:
bash-3.1# make install
mingw32-make: *** No rule to make target `boot/bootdata/i386/hivecls.inf',
needed by `reactos/system32/config/default'. Stop.
I tested some of GreatLord's regressions and I can see how Aleksey would
get angry about all the fixes he has to do to GreatLord's code, but
GreatLord has fixed a whole lot more than he has broken and Fireball
chasing around 'if (Foo == FALSE)' and changing it to 'if (!Foo)' seems
pointless. We've got plenty of code formatted as 'if (Foo == FALSE)' in
the kernel that works great. Aleksey is making more work for himself by
making needless changes to GreatLord's code. All that is needed is
someone with commit access that is willing to correct GreatLord's
comments. I don't have a problem with finding a regression of GL's here
or there. Sure he should test his code before committing but as far as
breakages, but his code usually correct and all coders create breakages
one time or another.
Hi,
I did some research and found something very interesting. I kept
thinking about the last DCE commit (34289). I had a guess and modified
the user32 test for wine. The results are very clear. Apparently
windows does not care for which dc is returned if it is Cached or a
bug since hWnd is the same. When DCX_NORESETATTRS is set when calling
GetDCEx; "Does not reset the attributes of this DC to the default
attributes when this DC is released." We do this correctly in
ReleaseDC. So the next GetDCEx should keep the original DC data for
the next set of tests. Wine test is completely incorrect. So all of
our DCE attributes code is good to go. Windows did not pass the
modified "Same hDC" check and we still fail the "ROP" check. See the
windows results at the end of this message.
////////
Changes to user32/tests/dce.c:
ReleaseDC( hwnd_cache, hdc );
hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE | DCX_NORESETATTRS );
<------ DCX_NORESETATTRS
rop = GetROP2( hdc );
ok( rop == def_rop || rop == R2_WHITE, "wrong ROP2 %d after
release\n", rop );
ReleaseDC( hwnd_cache, hdc );
+ old_hdc = hdc;
hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE );
rop = GetROP2( hdc );
+ ok( old_hdc == hdc, "didn't get same DC %p/%p\n", old_hdc, hdc );
ok( rop == def_rop, "wrong ROP2 %d after release\n", rop );
ReleaseDC( hwnd_cache, hdc );
/* test own DC */
////////
////////
Results from XP:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
Z:\>e:
E:\>user32_crosstest dce
dce.c:79: Test failed: didn't get same DC F5010866/FC0107E0
dce: 77 tests executed (0 marked as todo, 1 failure), 0 skipped.
E:\>
/////////
I also agree.
About the last point, in Ged's mail, I'm afraid to say I've real
difficulties to code with such build time. I'm obliged to work on outdated
revisons, and on partial builds. That's really insane.
P. Schweitzer
--------------------------------------------------
From: "gedmurphy" <gedmurphy(a)gmail.com>
Sent: Wednesday, July 02, 2008 5:49 PM
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll
> I completely agree, this needs to be clamped down on. Do we really need 78
> different keyboard layouts at this point?
> It's fine for the people with mega fast systems and time on their hands,
> but
> most people don't fall into this category.
>
> I now try to avoid building as much as possible and I suspect more people
> will be following suit if the build time continues to increase.
>
> Ged
>
>
Once again I agree, and I'd like to add my 2 cents, perhaps it will help.
We need two solutions right now. A short term one, and a long term one.
The short one, purposed by Ged seems, IMO, to be a nice alternative before
more important work, and seems to be quite easy to realize.
The long one could be a work on rbuild (and makefile) with the hierarchy
purposed by Ged. And instead of typing make bootcd, we would have to type
make bootcd X where X would be the additionnal components with hierarchy.
P. Schweitzer
--------------------------------------------------
From: "gedmurphy" <gedmurphy(a)gmail.com>
Sent: Thursday, July 03, 2008 9:19 AM
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll
> I'm certainly not asking him to stop. But I do think we need a rethink of
> our tree structure.
> The rosapps thing has never been ideal either, so moving stuff into there
> isn't a good solution.
>
> Perhaps we need a hierarchy of components listed for importance. Let's say
> the list ranges from 1 to 10. 1 being core components required to boot the
> OS, 2 being additional components to get to the GUI, etc, with 10 being
> things like these keyboard dlls I used as an earlier example.
>
> However, such a solution isn't a 5 minute job so we do need a quick fix in
> the meantime. Maybe something similar to how rosapps works, with an
> addition
> to the /modules rbuild file?
>
> Ged.
>
> -----Original Message-----
> From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On
> Behalf Of Aleksey Bragin
> Sent: 02 July 2008 22:34
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll
>
> Asking Dmitry to abstain from work would be considered "a hack", not
> "a proper solution".
>
> WBR,
> Aleksey.
>
> On Jul 3, 2008, at 12:45 AM, Heis Spiter wrote:
>
>> I also agree.
>> About the last point, in Ged's mail, I'm afraid to say I've real
>> difficulties to code with such build time. I'm obliged to work on
>> outdated
>> revisons, and on partial builds. That's really insane.
>>
>> P. Schweitzer
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hi,
Something else: there are two FORCEINLINE functions in
ntoskrnl/include/internal/ntoskrnl.h, DefaultSetInfoBufferCheck() and
DefaultQueryInfoBufferCheck(), but they cannot be inlined because of SEH
(i.e. setjmp/longjmp).
Timo Kreuzer wrote:
> What about wrapping the _SEH_TRY part in a local inline function? In my
> tests this successfully prevented the variables from being optimized away.
> At least under normal optimisation settings.
>> I now try to avoid building as much as possible and I suspect more people
>> will be following suit if the build time continues to increase.
>
> We could develop a lean target that only builds the bare apps and
> libraries required.
That's one of the things I experimented with while working on my C# rbuild
implementation http://www.marcpiulachs.com/reactos/designer.html . My
intention is to end up adding that kind of Platform Builder like feature to
our C++ implementation
Regards,
/Marc
Um...
KiDeliverApc already sets KernelApcPending = FALSE; Now you're setting
it twice...please revert.
On 1-Jul-08, at 3:08 AM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Tue Jul 1 05:08:14 2008
> New Revision: 34230
>
> URL: http://svn.reactos.org/svn/reactos?rev=34230&view=rev
> Log:
> - Fix a problem with normal and special APCs being inserted in the
> wrong order, spotted by Jury Sidorov. Now Borland Turbo Debugger
> should be able to debug applications, also it can fix hangs in other
> applications.
> - When delivering kernel APC, set the pending flag to false (by
> analogy with delivering user APC and clearing its pending flag).
> See issue #3426 for more details.
>
> Modified:
> trunk/reactos/ntoskrnl/ke/apc.c (contents, props changed)
>
> Modified: trunk/reactos/ntoskrnl/ke/apc.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/apc.c?rev=3423…
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- trunk/reactos/ntoskrnl/ke/apc.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ke/apc.c [iso-8859-1] Tue Jul 1 05:08:14
> 2008
> @@ -145,8 +145,8 @@
> /* Get the APC */
> QueuedApc = CONTAINING_RECORD(NextEntry, KAPC,
> ApcListEntry);
>
> - /* Is this a Normal APC? If so, break */
> - if (QueuedApc->NormalRoutine) break;
> + /* Is this a No-Normal APC? If so, break */
> + if (!QueuedApc->NormalRoutine) break;
>
> /* Move to the next APC in the Queue */
> NextEntry = NextEntry->Blink;
> @@ -320,6 +320,9 @@
> break;
> }
>
> + /* It's not pending anymore */
> + Thread->ApcState.KernelApcPending = FALSE;
> +
> /* Get the next Entry */
> ApcListEntry = Thread->ApcState.ApcListHead[KernelMode].Flink;
> Apc = CONTAINING_RECORD(ApcListEntry, KAPC, ApcListEntry);
>
> Propchange: trunk/reactos/ntoskrnl/ke/apc.c
> ------------------------------------------------------------------------------
> --- svn:needs-lock (original)
> +++ svn:needs-lock (removed)
> @@ -1,1 +1,0 @@
> -*
>
Best regards,
Alex Ionescu
Hello everyone,
As most devs including me noticed this "the input line is too long" bug
after hpoussin's changes in r34187 to r34191, I did some research on it.
Unfortunately, it looks like it's unfixable if we keep on directly using ld
for linking (as introduced in these revisions) instead of calling the gcc
frontend.
First of all, the "length" of the cmd input line under Windows seems to be
highly affected by quotation marks. If you add a quotation mark to the
working linker command line before hpoussin's commits, it will also be
reported as being too long.
Previously, we didn't use quotation marks in the command line when linking
the binaries.
Now we have to do this because of the changed PROJECT_LFLAGS and
PROJECT_LPPFLAGS variables: They contain the path to i.e. libgcc and as this
path can contain spaces, it has to be put in quotation marks. Just passing
"libgcc.a" without a path doesn't work.
Passing "-lgcc" also doesn't work, because mingw32-ld only seems to search
for libraries in "mingw32/lib", not "lib/gcc/mingw32/4.1.3" as gcc does.
I see no other solution than partly reverting hpoussin's changes and using
gcc for linking again.
If anyone sees another option, please comment or directly commit a fix.
Best regards,
Colin
On Sat, Jun 28, 2008 at 10:58 PM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> +The views and conclusions contained in the software and documentation are those of the authors and
> +should not be interpreted as representing official policies, either expressed or implied, of the ReactOS
> +Project.
Sounds like the Ninja's don't want a libel lawsuit. =)
I don't see anything in this clause that is not GPL compatible, its just funny.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
Generate? fat.h and fat32.h are already included in the code base ,
installfreeldr will compile without problems
Regards,
/Marc
--------------------------------------------------
From: "Hervé Poussineau" <hpoussin(a)reactos.org>
Sent: Thursday, June 26, 2008 7:43 PM
To: <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [mpiulachs] 34106: - remove no
longerrequired bootsect.mak
> Hi,
>
> mpiulachs(a)svn.reactos.org a écrit :
>> Author: mpiulachs
>> Date: Thu Jun 26 10:58:56 2008
>> New Revision: 34106
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=34106&view=rev
>> Log:
>> - remove no longer required bootsect.mak
>>
>> Removed:
>> trunk/reactos/boot/freeldr/bootsect/bootsect.mak
>>
>
> Which rbuild file tells how to generate the files
> reactos/boot/freeldr/bootsect/fat.h and fat32.h?
> They are required by reactos/boot/freeldr/install/install.c.
>
> The inclusion of install/installfreeldr.rbuild has been removed in
> r34055. I don't know if it is an error or not.
>
> Hervé
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
mpiulachs(a)svn.reactos.org a écrit :
> Author: mpiulachs
> Date: Thu Jun 26 10:58:56 2008
> New Revision: 34106
>
> URL: http://svn.reactos.org/svn/reactos?rev=34106&view=rev
> Log:
> - remove no longer required bootsect.mak
>
> Removed:
> trunk/reactos/boot/freeldr/bootsect/bootsect.mak
>
Which rbuild file tells how to generate the files
reactos/boot/freeldr/bootsect/fat.h and fat32.h?
They are required by reactos/boot/freeldr/install/install.c.
The inclusion of install/installfreeldr.rbuild has been removed in
r34055. I don't know if it is an error or not.
Hervé
Grievance: Cease and Desist Request: Standard Resolution Procedure:
1) The Project Coordinator Should attempt to make decisions according
to the consensus of the Project Members.
Mr. Bragin is making procedural changes with out the full consensus of
all Project Members.
2) The Repository Coordinator Should make decisions which are fair and
reasonable, and preferably consistent with the consensus of the
Project Members.
Due to the unfilled Repository Coordinator position, Mr. Bragin has
assumed full control of that position and making decisions with out
the full consensus of all Project Members.
3) General rules:
a) Violation of first rule: Project Coordinator issued change orders,
Project Members began working on the changes. These changes are
against the general consensus among the Project Members. Reference:
http://www.reactos.org/archives/public/ros-dev/2008-June/010394.html
b) Violation of second rule: Project Coordinator banned Project Member
with out the ability to rejoin the Project at any time.
c) Violation of third rule: Project Coordinator assumed full control
of Repository Coordinator position and used that position to remove
access to a Project Member.
Adhering to: Standard Resolution Procedure: The procedure: The
procedure begins when a draft General Resolution is announced on a
public Project mailing list. Which no other rule can apply, I hereby
request a Cease and Desist until this Grievance is heard by all
Project Members. Project Members have a contractual agreement and must
abide by it.
PS: This is a very serious mater and not at all a joke. If this
project has any merit, it needs to resolve these issues in the open.
We have two different ways to do the same thing. Modules have a "host"
attribute to indicate if the module has to be build by host compiler rather
than target compiler but we also have the "hoststaticlibrary" module type ,
I don't know if "host" property is broken but someone with time should
test/fix it as it's the more appropiate way.
Marc,
--------------------------------------------------
From: <cfinck(a)svn.reactos.org>
Sent: Sunday, June 22, 2008 11:41 PM
To: <ros-diffs(a)reactos.org>
Subject: [ros-diffs] [cfinck] 34051: Build host_wcsfuncs as a host static
library, not a target static library Fixes build for all non-Win32 hosts
> Author: cfinck
> Date: Sun Jun 22 16:41:25 2008
> New Revision: 34051
>
> URL: http://svn.reactos.org/svn/reactos?rev=34051&view=rev
> Log:
> Build host_wcsfuncs as a host static library, not a target static library
> Fixes build for all non-Win32 hosts
>
> Modified:
> trunk/reactos/lib/host/wcsfuncs/wcsfuncs.rbuild
>
> Modified: trunk/reactos/lib/host/wcsfuncs/wcsfuncs.rbuild
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/lib/host/wcsfuncs/wcsfuncs…
> ==============================================================================
> --- trunk/reactos/lib/host/wcsfuncs/wcsfuncs.rbuild [iso-8859-1]
> (original)
> +++ trunk/reactos/lib/host/wcsfuncs/wcsfuncs.rbuild [iso-8859-1] Sun Jun
> 22 16:41:25 2008
> @@ -1,6 +1,6 @@
> <?xml version="1.0"?>
> <!DOCTYPE module SYSTEM "../../../tools/rbuild/project.dtd">
> -<module name="host_wcsfuncs" type="staticlibrary">
> +<module name="host_wcsfuncs" type="hoststaticlibrary">
> <include base="ReactOS">include</include>
> <file>wcsfuncs.c</file>
> </module>
>
>
@Jimtabor: do you have a better candidate for ROS project coordinator post
than Fireball? Not that i see many likely candidates.
For some time i prefered to stay silent, not to take part in this outcry...
But this forced me to do otherwise:
> MY final word:
>I deleted all code I have been working on so do not ask for it, This
>is final word from me and bye from my part from this project you have
>great thanks to fireball why I quitting.
Great... i thought you were older and a bit more mature. This is not better
than a 13y old boy, crying, offended by the whole world, wanting to avenge
himself. Childish, childish, childish...
>One thing more do not forget that steven is starting paying some of the
devs
>in ReactOS , he and fireball are trying to go Commercial so they trying
>shutdown ReactOS and make it into project codename unros. This info is not
>public and only few devs known of it, and of cures he will deny this.
One more thing, it is a secret, that Magnus Olsen has been bought off by
Microsoft, to leave ReactOS and, in the process to stirr and agitate ROS
team. He has been already paid a hefty sum in advance. This info is not
public and only handfull of people know it. Magnus will, of course, deny all
of this.
Seriously, in my country, we have a saying: "If God wishes to punish
someone, he starts with stripping one of his brain". Nuff said...
Hi
I am not returning anytime soon to reactos until everthing has been restored by fireball. He has removed my commit access to reactos for the reason he dislikes my spelling and code style. He demands every thing I code, must be approve by him. So I am not coming back until this has all changed. With full restored commit access.
On Sun, Jun 15, 2008 at 12:05 PM, <cfinck(a)svn.reactos.org> wrote:
> This patch has already been submitted to Wine, but as they don't care currently, I applied it manually here and updated "comctl32_ros.diff" accordingly.
You might resend after next week. 1.0 should be tagged Monday or
sometime shortly there after and so Alexandre should start ignoring
patches as normal rather than blaming it on the late hour of the code
freeze.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Did this glitch appear in windows too?
I don't remember seeing this, and I have a feeling this patch is hiding an underlying bug.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of jimtabor(a)svn.reactos.org
Sent: 14 June 2008 18:11
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [jimtabor] 33965: Patch by carlo bramix at libero dot it: Bug 3336 statusbar in the wrong place.
Author: jimtabor
Date: Sat Jun 14 12:10:55 2008
New Revision: 33965
URL: http://svn.reactos.org/svn/reactos?rev=33965&view=rev
Log:
Patch by carlo bramix at libero dot it: Bug 3336 statusbar in the wrong place.
Modified:
trunk/reactos/base/applications/games/solitaire/solitaire.cpp
Modified: trunk/reactos/base/applications/games/solitaire/solitaire.cpp
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/games/so…
==============================================================================
--- trunk/reactos/base/applications/games/solitaire/solitaire.cpp [iso-8859-1] (original)
+++ trunk/reactos/base/applications/games/solitaire/solitaire.cpp [iso-8859-1] Sat Jun 14 12:10:55 2008
@@ -496,6 +496,7 @@
{
MoveWindow(SolWnd, 0, 0, nWidth, nHeight - nStatusHeight, TRUE);
MoveWindow(hwndStatus, 0, nHeight - nStatusHeight, nWidth, nHeight, TRUE);
+ SendMessage(hwndStatus, WM_SIZE, wParam, lParam);
}
else
{
If a student is currently taking, or has previously taken a course
derived from the Microsoft Windows Academic Program
http://www.microsoft.com/resources/sharedsource/windowsacademic/default.mspx
which contains the curriculum resource kit, Windows Research Kernel
(containing Windows XP x64 amd Server 2003 SP1 kernel sources) and
Project OZ,
will they become *ineligible* to contribute code to the ReactOS
project in the future?
Thanks!
Mark
Hello,
would it be possible to get a dump or a copy of the ReactOS SVN
repository, so I can move the code and history of Explorer and
IBrowser (may be also Winefile) into my own repository - as you seem
to want removing it?
May be the simplest way would be to give me temporary shell access to
svn.reactos.org, so I can dump and filter it myself.
Regards,
Martin
2008/5/23 Steven Edwards <winehacker(a)gmail.com>:
> On Thu, May 22, 2008 at 8:59 PM, Dan Kegel <dank(a)kegel.com> wrote:
>> The menus are messed up (they contain garbage text), and
>> as I said earlier, there's no start menu.
>
> You should look at explorer-new. Its in the ReactOS source tree and
> being developed by Thomas Weidenmuller as a real Windows compatible
> shell replacement. Unfortunately it does not work on Windows or
> ReactOS at this time. The old ReactOS explorer will be removed when
> explorer-new is ready.
>
>
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo
--
Martin Fuchs
martin-fuchs(a)gmx.net
Hi,
Thanks Goplat for fixing this,,,, pleas let me know via Developer mail
list if I fubar a patch... I can not get access via my work network to
the web site. They blocked it, 8^(
Google works~
Thanks,
James
On Mon, Jun 9, 2008 at 4:57 PM, <tkreuzer(a)svn.reactos.org> wrote:
> See issue #2142 for more details.
Is there anyway we can add a macro so that when the commit message see's
"See issue #### for more details."
It will auto magically link to bugzilla? I would look at more bugs as
the patches come in but I am too lazy to manually open another tab and
copy/paste the bug number. I could set a macro in firefox where I do
"bug ####' but that means I still have to manually open a new tab and
copy and paste, like I said I am lazy.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
HI
I am been rethinking over some thing in ReactOS
mean while I will not be avail coding on ReactOS at all
or do any commit or helping people as I use to.
I am still piss over some matter betwin me and Alesky
this matter is betwin us two. What happen betwin us
is betwin us. That is all I have say for now. about
that matter.
And I am rethinking over a sugestions I got from a old
freind maybe start working for him. I do not known
if I do i can not be coding on any opensource project
the contract is for long terms contract and will need
all skill I have. I got this offer for long time ago
and I did say no to it, but it still stand,
reason I did say no to it was I did not want coding behine dorrs or
come up new ideas that being use behine dorrs and u are not avail
to talk about them. I see allot of my life works are being using of
all people that own a laptop or cellphone today.
But one can backtrace the techlogic to me. what I done.
That is how I did want thing be when I was younger.
it is some background info what I did before 2003
after I join ReactOS most people I known ask me if I can quit
from ReactOS and start working for them. One video card manufactor
did contact me when I join ReactOS I can not tell which one.
I solv the main issue I and the manufactor did have.
it was how to open directx hal for the graphic card.
next issue I solv was how to create a surface and access all other
part of directx hal. Next issue we got was DirectX DdBlt it did not
work direcly it took me and the manufactor around 2 days figout
how to use DdBlt so it was avail to blit and see it on the screen.
This informations did not exstis at all in MSDN. after I told open
how it was done and start implemeted it in reactos MS did update the
doc how to optain DirectX HAL. See GdiEntry1-16
This does not mean I am leving ReactOS
it mean I need rethink what I want todo
the options I got is very good one. I like
the offer I got. and I do not known if I will say yes or no
I am not a person say direcly no to money but none can buy me
for money. I choice what I want todo. even it is bad payment.
I have say no to many good deal and work in pass.
Steven
what I told u before, I stand with my word, and waiting on
you mail about the details.
To reash me is not via irc any longer
it is on icq / skype or my mail address.
Bestregards
Magnus Olsen
Hi,
this question seems to arise periodically, so let's have a
constructive discussion again about the issue once again.
The issue is being that a lot of people have direct commit access to
the repository, and sooner or later some of them commit patches which
introduce a regress in functionality.
I will use Magnus (GreatLord) again as an example. He was doing a
good thing (as usual), but then somehow lost focus, and along with
good fixes committed a breakage for FF2.0 installer (and all other
apps using PatBlt functions). I had to (as usual!) spend the whole
morning reviewing all his diffs, then regress-testing by bisection to
find the guilty revision, then work out a better solution with him,
and then come to agreement that the guilty commit could be just
reverted for now, since it partly works anyway.
This takes up significant amount of my time, which could go into
something more productive than just testing patches, finding way to
unregress, and so on.
Especially I'm angry about this happening right when approaching
0.3.5 release.
Ideally (as I explained in #reactos today to blight_), I want the
trunk itself be directly committable only by a very limited number of
persons, and all developers should be committing to "some other
place" at first, and then their patches merged by reviewers/testers
(yes, manually, sometimes just reviewing may be enough to commit/
reject the patch, sometimes a thorough testing must be involved,
maybe additional devs asked for a review).
blight_ called this as a "linux development model" with an
intermediate branch - yes, maybe, why not?.
What I definately don't want to do is to scare developers away and
make their life more complicated by need of sending text patches
(this is just not convinient, and as seen on the example of Wine
makes a lot of possible contributors going away).
I remember what Alex proposed (those who don't, may look up ros-dev
ML archives with a similar topic).
Would there be any new prepositions? Maybe someone discovered a new
CIS for SVN, or a decentralized VCS for patch submission and usual
SVN for maintaining HEAD?
With time, developers number is only going to increase, so this
problem will become more and more annoying.
With the best regards,
Aleksey Bragin.
Hi,
I'm going to explain this ONCE:
1st: The move was to conserve and reduce space and size of the current
structure.
Writing a floating point package could be hard to do or just copyleft
one off the net.... Problem is if we do the later it will most likely
not be compatible with M$ SFPP. BTW, M$ did patent their strange and
unusual floating point package. Which means I can not write one! Just
writing the storage emulation is almost a problem too... But due to US
patent law I can just do what I did, to "Talk to the Interface" with
the storage emulation.
Keeping the current state of ReactOS FP is my first choice. We use the
speed of the FPU which is part of the main processor and reduce the
size of the source. (Two pluses so far, Speed and Small Size.) The
storage emulation for gdi32 is important for compatibility and with
ReactOS concept of drop in replacement and play.
Thanks,
my 1EU
References:
Fast floating-point truncation to integer form - US Patent 6535898:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6535898&F=0
Use of indices for queries with comparisons based on a function:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1193619&F=0
System and method for fast and smooth rendering of lit, textured spheres:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1227443&F=0
John R. Hauser SoftFloat package :
http://www.jhauser.us/arithmetic/SoftFloat.html
IEEE 754 floating-point test software:
http://www.math.utah.edu/~beebe/software/ieee/
Hi,
I experience a hang of FF 1.5 installation app at "0% Extracting".
Sometimes hangs completely (even mouse doesn't move), sometimes I'm
able to click "X" and choose yes to cancel.
It started happening at least since yesterday.
WBR,
Aleksey Bragin.
Hi,
I like to start testing FF again on hardware but this bug is still open.
http://www.reactos.org/bugzilla/show_bug.cgi?id=2987
I've copied most of the netamd.inf from Ros to match with the inf for
the driver. But still the same crash.
Please let me know,
James
Hi!
There was a reason for doing what I commit'ed,,,, since you are
looking at it can you please fix this.
8^)
James
gdi32_winetest pen
ExFreePool of already freed address 80e8ba78
KeBugCheck at ntoskrnl/mm/npool.c:1566
*** Fatal System Error: 0x00000000
(0x00000000,0x00000000,0x00000000,0x00000000)
Entered debugger on embedded INT3 at 0x0008:0x808ac7d8.
kdb:> bt
Eip:
<NTOSKRNL.EXE:ac7d9 (lib/rtl/i386/debug_asm.S:42
(RtlpBreakWithStatusInstruction))>
Frames:
<NTOSKRNL.EXE:29a2 (ntoskrnl/ke/bug.c:1100 (KeBugCheckWithTf@24))>
<NTOSKRNL.EXE:2aac (ntoskrnl/ke/bug.c:1364 (KeBugCheck@4))>
<NTOSKRNL.EXE:5f00c (ntoskrnl/mm/npool.c:1567 (ExFreeNonPagedPool@4))>
<NTOSKRNL.EXE:61e64 (ntoskrnl/mm/pool.c:238 (ExFreePool@4))>
<win32k.sys:967ff (subsystems/win32/win32k/objects/pen.c:344
(NtGdiExtCreatePen@44))>
<NTOSKRNL.EXE:96eda (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5dda>
<gdi32_winetest.EXE:3b497>
<gdi32_winetest.EXE:3d605>
<gdi32_winetest.EXE:3d78d>
<gdi32_winetest.EXE:3dc3d>
<gdi32_winetest.EXE:3dc6a>
<kernel32.dll:21610>
<00000000>
On Tue, Jun 3, 2008 at 5:08 PM, Colin Finck <mail(a)colinfinck.de> wrote:
> The Wine test framework is currently only used by tests imported from Wine,
> so an own test suite for ws2_32.dll might get lost there.
You could have written the tests for the wine test suite and submitted them.
> Also Timo's testing framework offers some interesting features like HTML
> output not offered by the Wine one.
Sure, but given the size of the wine test suite verses Timo's I think
the effort is
better spent adding this to winetest
> Additionally, we have a free hand here and can play with it as we want,
> while we can only import and maybe make little changes to the Wine test
> framework if we want to avoid a big merging mess.
Your always free to fork. As I said given the large number of unit
tests in the Wine framework
it seems to make more sense to me to extend that rather than develop a new one.
Besides you can add the features you need to the Winetest gui and have
it be independent
of the framework as a whole.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I'm getting *quite* annoyed with seeing these kinds of tests:
ret = SomeFunc();
ASSERT(ret == success);
How exactly is this a test anyway? It proves in NO way that the
function *worked*, only that it returned success. Furthermore, there
are *plenty* of cases where a function could legitimately fail -- it
is simply stupid to assume that a failure means a regression. What if
the system is out of memory?
On Sun, Jun 1, 2008 at 10:38 PM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Sun Jun 1 09:38:02 2008
> New Revision: 33807
>
> URL: http://svn.reactos.org/svn/reactos?rev=33807&view=rev
> Log:
> add Test for EngDeleteSemaphore, it only test if it been create or not
>
> Added:
> trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c (with props)
> Modified:
> trunk/rostests/apitests/gdi32api/testlist.c
>
> Modified: trunk/rostests/apitests/gdi32api/testlist.c
> URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/gdi32api/testlis…
> ==============================================================================
> --- trunk/rostests/apitests/gdi32api/testlist.c [iso-8859-1] (original)
> +++ trunk/rostests/apitests/gdi32api/testlist.c [iso-8859-1] Sun Jun 1 09:38:02 2008
> @@ -11,6 +11,7 @@
> #include "tests/CreateFont.c"
> #include "tests/CreatePen.c"
> #include "tests/CreateRectRgn.c"
> +#include "tests/EngCreateSemaphore.c"
> #include "tests/ExtCreatePen.c"
> #include "tests/GdiConvertBitmap.c"
> #include "tests/GdiConvertBrush.c"
> @@ -51,6 +52,7 @@
> { L"CreateCompatibleDC", Test_CreateCompatibleDC },
> { L"CreateFont", Test_CreateFont },
> { L"CreatePen", Test_CreatePen },
> + { L"EngCreateSemaphore", Test_EngCreateSemaphore },
> { L"CreateRectRgn", Test_CreateRectRgn },
> { L"ExtCreatePen", Test_ExtCreatePen },
> { L"GdiConvertBitmap", Test_GdiConvertBitmap },
>
> Added: trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c
> URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/gdi32api/tests/E…
> ==============================================================================
> --- trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c (added)
> +++ trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c [iso-8859-1] Sun Jun 1 09:38:02 2008
> @@ -1,0 +1,15 @@
> +/* Simple test of EngAcquireSemaphore only check if we got a lock or not */
> +INT
> +Test_EngCreateSemaphore(PTESTINFO pti)
> +{
> +
> + HSEMAPHORE hsem;
> + hsem = EngCreateSemaphore();
> +
> + RTEST ( hsem != NULL );
> +
> + EngDeleteSemaphore(hsem);
> +
> + return APISTATUS_NORMAL;
> +}
> +
>
> Propchange: trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
>
--
Best regards,
Alex Ionescu
Hi!
I checked this and it is all wrong,,,,, I reverted part of revision 19267:
Replacing the code with the original wine code that behaves like
"Windows code" but should be called inside EngCreateBitmap if (pvBits)
Width = DIB_GetDIBWidthBytes( lWidth, iFormat); .
As it should be:
INT FASTCALL DIB_GetDIBWidthBytes (INT width, INT depth)
{
// return ((width * depth + 31) & ~31) >> 3;
int words;
switch(depth)
{
case 1: words = (width + 31) / 32; break;
case 4: words = (width + 7) / 8; break;
case 8: words = (width + 3) / 4; break;
case 15:
case 16: words = (width + 1) / 2; break;
case 24: words = (width * 3 + 3)/4; break;
default:
DPRINT1("(%d): Unsupported depth\n", depth );
/* fall through */
case 32:
words = width;
}
return 4 * words;
}
On Sat, May 31, 2008 at 7:15 PM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Sat May 31 18:15:34 2008
> New Revision: 33792
>
> URL: http://svn.reactos.org/svn/reactos?rev=33792&view=rev
> Log:
> preserve code for NtGdiCreateEnhMetaFile from win32k (where it's going to be removed later) in gdi32 (where it's going to be implemented later)
if your going to implement it all in usermode are you going to try to
just rip the Wine metafile and enhanced metefile drivers?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I hope everyone is clear in his mind about the fact that this makes up
20 % of the complete reactos source or in other words increases the size
of the code by 25% ...
> [ros-diffs] [hyperion] 33703: added nls added nls/3rdparty added nls/3rdparty/icu We
> officially welcome IBM's excellent ICU4C library for Unicode support to
> our humble source tree. May our marriage be long, happy and fertile.
>
>
Hi,
Owner Menu Drawing if I remember right, which allows application to
draw their own menus. Yes that is right! Not all applications use MDI.
Well, it is now all broken (It was in a state of NEAR DO WELL). I
understand the reason for wine testing but please understand What You
See Is What You Get.
>From the debug output:
IntSetMenuItemInfo: Invalid combination of fMask bits used
It draws a small little box with the line separators. 8^' looks cute~
I need to stay focus on the issues I'm working on,, please help me by
fixing this new issue, please don't send me patches,
8^)
James
On Thu, May 29, 2008 at 9:27 PM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Thu May 29 20:27:29 2008
> New Revision: 33764
>
> URL: http://svn.reactos.org/svn/reactos?rev=33764&view=rev
> Log:
> 1. do not use wine def for reactos
> 2. this is almost 100% correct list of windows 2003 export list of msvcrt.def and it will make abiword working again for it was missing api wfreopen and allot more api from msvcrt
> 3. this add back api that was remove api they exists in windows 2003 export list
> 4. List was provide from colin f
>
> See issue #3293 for more details.
I'd suggest putting a comment at the top of the def so that in the
future someone won't make this mistake again. Any idea why it works on
Wine with the missing exports but not ReactOS?
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
Could it be easier to just:
static GDIDEVICE PrimarySurface;
PGDIDEVICE pPrimarySurface = &PrimarySurface;
then use pPrimarySurface through out? I will have to rewrite
everything later to support the new HDEV code.
IDEA~! Stefan100 theres a good patch! ;^D
Thanks,
James
On May 28, 2008, at 4:41 AM, tkreuzer(a)svn.reactos.org wrote:
> 1.28: Jonathan Ernst <jonathan(a)ernstfamily.ch>
> Update the address of the Free Software Foundation.
This should fix a lot of crashes, since many apps would try to
dereference FSF's address, but it would be invalid!
:-)
WBR,
Aleksey Bragin.
On Fri, May 23, 2008 at 1:55 PM, <fireball(a)svn.reactos.org> wrote:
> - msiexec is GUI app, not CUI.
Is this a Wine bug then? It has it listed as a console based
application. When you run msiexec directly on Windows I know it does
not start a console window so I guess this would imply it is a GUI
with a hidden window right?
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
On Tue, May 20, 2008 at 8:53 AM, <dchapyshev(a)svn.reactos.org> wrote:
> +#include "../kbswitch.h"
Could you set an include path and remove the ../ from the source?
gnumake throws a fit with parallel makes and relative paths.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
If GetWindowsDirectory fails, you have much worse issues to worry
about than executable redirection.
Also note that regedt32.exe is usually in the system32 directory, so
how is this a security/redirection issue exactly?
This implies someone would have to:
1) Give you a malware regedit.exe in directory foo
2) Give you the legitimate regedt32.exe in directory foo
3) Somehow convince you to:
3.1) Use regedt32 instead of regedit (few people even know this tool)
3.2) Launch regedt32 from this "foo" directory instead of using
start/run regedt32
The issue you're looking for just doesn't exist.
2008/5/19 FENG Yu Ning <fengyuning1984(a)gmail.com>:
> On Sun, May 18, 2008 at 7:28 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>>
>> Last nitpick: if you can't get the windows directory, just
>> ShellExecute "regedit.exe" directly, as the code originally did --
>> this is the behavior on Windows, fyi.
>>
>
> Though it is the behavior on Windows, it is a bad thing, IMHO. There are
> already too many little viruses who pretend to be a system executable, say,
> explorer.exe, and they are placed in a (sub)directory of the windows
> directory to be shell executed. If we can't get the windows direcoty, we
> should let the user know, and give them the chance to fix it, instead of
> blindly execute anything.
> I used to suffer from those, and they were really annoying. Please consider
> being different from Windows in this and similar issues.
> MHO.
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
--
Best regards,
Alex Ionescu
--
Best regards,
Alex Ionescu
Hi,
I warn you guys about the menu code, so far everything looks okay.
Fireball: "guys, dlls/win32k/user32/menu.c" "line 240" "it HeapFrees
ItemInfo->dwTypeData" "but who HEapAllocates it?!", Answer the Q.
MenuGetRosMenuItemInfo does.... Please understand I worked my ass off
back on 0.3.0? to fix the mess in user32 menu. Please Think before you
Code. Have a list of test apps to make sure it does work like YOU
think it should. Wine is not enough!.
Thanks,
James
As a ReactOS-User I thoght sometimes, which is better: ReactOS or Linux with WINE.
WINE is much more mature and can also run Windows 3.11 programs.
But ReactOS - on the other side - is more Windows-like. It is a complete Operating System like Windows. And the applications for ReactOS can also be running in binary form on Windows and are not Linux-/Unix-native applications which are additional compiled against a winelib.dll.
On the ReactOS-side stand the everyone known text
"ReactOS aims to achieve complete binary compatibility with both applications and device drivers meant for NT and XP operating systems, by using a similar architecture and providing a complete and equivalent public interface."
That is one of the differences to WINE: Being also driver-compatibe to XP.
But thats also a point, where I ask myself, how much sense this make.
Windows NT could run a lot of Windows 95/98 programs. Windows XP could run most Windows NT, Windows 9x and Windows 3.x programs. Windows Vista runs not all but some of the Windows XP and Windows NT programs.
But on the driver side, Windows XP could only some Windows NT driver (like printer-driver).
As I read for some time, for Windows Vista existing lesser driver then for Linux. So, it seems not, that Vista could use some of the plenty of Windows XP driver.
Also Vista existing as 32bit and 64bit. And the 64bit system can not use 32bit driver.
Follower of Vista (for example Windows 7) will only be existing as 64bit system.
So, you want to be driver-compatibe to Windows. But Windows will itself not be drivercompatibe to older or newer versions.
I have read anywhere in the Internet, that it is planned, that in newer Windows-versions only driver can be used and installed, which are trustable. And only Microsoft dicide, which drivers are trustable and which not. And driver-creator have ro pay on Microsoft that they make the drivers authorized/trustable.
This makes it also more senseless to be driver-compatibe to Windows.
But ReactOS have the advantage, that it looks and feels in all areas like Windows. And you can run Windows-programs on it. That is really an advantage of ReactOS.
Possible ReactOS would be anytime cooperate with DeviceVM ( the company behind SplashTop http://www.splashtop.com/index.php ) . Because it is possible, that there are people who would prefer an Windows/ReactOS system which starts fast on an RAM instead of an Linux-System.
In the new Newsletter (#41) of ReactOS stands, that Steven Edwards comes back to interact again between ReactOS and WINE.
Thats a very good news. Hopefully all the WINE-developers see ReactOS in some time as legal and use again ReactOS-code for WINE, so that ReactOS and WINE could again more cooperate.
There are still some developer (like GvG and others) who have left ReactOS and thought, that ReactOS isn't legal in USA-laws. I still think, that it is a big problem, that there are some ex-developer of ReactOS and some WINE-developer, who beliefs, that ReactOS is illegal. A more intensive dialog with this people is needed I think.
Greatings
theuserbl
_________________________________________________________________
Die aktuelle Frühjahrsmode - Preise vergleichen bei MSN Shopping
http://shopping.msn.de/category/damenbekleidung/bcatid66/forsale?text=categ…
Maybe _tcscat_s should be used instead ?
Kind regards,
Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net
----- Message d'origine ----
> De : Alex Ionescu <ionucu(a)videotron.ca>
> À : ros-dev(a)reactos.org
> Envoyé le : Samedi, 17 Mai 2008, 16h00mn 00s
> Objet : Re: [ros-dev] [ros-diffs] [cfinck] 33547: Make 100% sure that the correct "regedit.exe" is launched by using GetWindowsDirectory and appending "\regedit.exe" as suggested by Alex on ros-dev.
>
> This is still wrong. Tcscat is completely unsafe and can result in you
> overwriting the path as soon as the user has a windows path longer
> than MAX_PATH - sizeof("regedit.exe").
>
> Please use the PathAppend API for this.
>
> On Sat, May 17, 2008 at 5:39 PM, wrote:
> > Author: cfinck
> > Date: Sat May 17 04:39:36 2008
> > New Revision: 33547
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=33547&view=rev
> > Log:
> > Make 100% sure that the correct "regedit.exe" is launched by using
> GetWindowsDirectory and appending "\regedit.exe" as suggested by Alex on
> ros-dev.
> >
> > Modified:
> > trunk/reactos/base/applications/regedt32/regedt32.c
> >
> > Modified: trunk/reactos/base/applications/regedt32/regedt32.c
> > URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/regedt32…
> > ==============================================================================
> > --- trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1]
> (original)
> > +++ trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1] Sat May
> 17 04:39:36 2008
> > @@ -5,7 +5,12 @@
> > int WINAPI _tWinMain(HINSTANCE hCurInst, HINSTANCE hPrevInst,
> > LPTSTR lpsCmdLine, int nCmdShow)
> > {
> > - ShellExecute(NULL, NULL, _T("regedit.exe"), lpsCmdLine, NULL, nCmdShow);
> > + TCHAR szPath[MAX_PATH];
> > +
> > + GetWindowsDirectory(szPath, MAX_PATH);
> > + _tcscat(szPath, _T("\\regedit.exe"));
> > +
> > + ShellExecute(NULL, NULL, szPath, lpsCmdLine, NULL, nCmdShow);
> >
> > return 0;
> > }
> >
> >
>
>
>
> --
> Best regards,
> Alex Ionescu
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
This is still wrong. Tcscat is completely unsafe and can result in you
overwriting the path as soon as the user has a windows path longer
than MAX_PATH - sizeof("regedit.exe").
Please use the PathAppend API for this.
On Sat, May 17, 2008 at 5:39 PM, <cfinck(a)svn.reactos.org> wrote:
> Author: cfinck
> Date: Sat May 17 04:39:36 2008
> New Revision: 33547
>
> URL: http://svn.reactos.org/svn/reactos?rev=33547&view=rev
> Log:
> Make 100% sure that the correct "regedit.exe" is launched by using GetWindowsDirectory and appending "\regedit.exe" as suggested by Alex on ros-dev.
>
> Modified:
> trunk/reactos/base/applications/regedt32/regedt32.c
>
> Modified: trunk/reactos/base/applications/regedt32/regedt32.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/regedt32…
> ==============================================================================
> --- trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1] (original)
> +++ trunk/reactos/base/applications/regedt32/regedt32.c [iso-8859-1] Sat May 17 04:39:36 2008
> @@ -5,7 +5,12 @@
> int WINAPI _tWinMain(HINSTANCE hCurInst, HINSTANCE hPrevInst,
> LPTSTR lpsCmdLine, int nCmdShow)
> {
> - ShellExecute(NULL, NULL, _T("regedit.exe"), lpsCmdLine, NULL, nCmdShow);
> + TCHAR szPath[MAX_PATH];
> +
> + GetWindowsDirectory(szPath, MAX_PATH);
> + _tcscat(szPath, _T("\\regedit.exe"));
> +
> + ShellExecute(NULL, NULL, szPath, lpsCmdLine, NULL, nCmdShow);
>
> return 0;
> }
>
>
--
Best regards,
Alex Ionescu
Hi,
I thought it was a handle management problem but it seems to be just a
GetDC one. I found out when a pOWNED dc or dc owned by a window or
window class after the first GetDC the DCX_CACHE bit become set. This
is wrong behavior. Our UserGetDCEx code is a hodgepodge of wine and
poorly RE, coded by the original authors and does not comply with
known semantics. Sorry I guess? Well~ still rewriting it has become a
headache for me and I guess I'm asking for help. I have attempted more
than twice to rewrite it with porting wine code, etc. All ended in
major crashes, thus validating my claim, if you write code based on
bad code you end up with more bad code.
Using wine testing, Use32 dce test, everything works upto line 93.
hdc = GetDC( hwnd_owndc ); <----------------- first GetDC call
SetROP2( hdc, R2_WHITE );
rop = GetROP2( hdc );
ok( rop == R2_WHITE, "wrong ROP2 %d\n", rop );
old_hdc = hdc;
ReleaseDC( hwnd_owndc, hdc ); <---------------------- first ReleaseDC
hdc = GetDC( hwnd_owndc ); <---------------------------2nd GetDC
ok( old_hdc == hdc, "didn't get same DC %p/%p\n", old_hdc, hdc );
rop = GetROP2( hdc );
-> ok( rop == R2_WHITE, "wrong ROP2 %d after release\n", rop );
ReleaseDC( hwnd_owndc, hdc );
rop = GetROP2( hdc );
ok( rop == R2_WHITE, "wrong ROP2 %d after second release\n", rop );
After the first GetDC the DC is cached by setting bit DCX_CACHE and
this is wrong (BUG) since this DC is owned by a window. The second
GetDC is called and the DC is now a DCX_CACHE. The original data is
now lost due to the first ReleaseDC freeing DC_ATTR, thus normal
behavior for this type of DC with DCX_CACHE set. This results in the
failure at line 93 with the data in the DC_ATTR is set to a CleanDC
state. This is correct for DCX_CACHE'ed DC but not for DCX_WINDOW DC.
DCX_WINDOW DCs keep the original DC_ATTR data and it is not freed
after a ReleaseDC call. The same goes on with class DC tests.
The BUG is in UserGetDCEx, the freeing and allocating DC_ATTR is
correct but somewhere the DCX_CACHE bit get set and that should not
happen for window/class owned DCs.
I hope this clears it up.
I need someone with fresh eyes to help us fix this.
Thanks,
James
I've had enough of dealing with the suckiness of rbuild. The time has
come for action. Or, missing that, a wiki page:
<URL: http://www.reactos.org/wiki/index.php/Rbuild_sucks>
Add your own favourite issue with rbuild. Let's debate the more
controversial points in the wiki page's discussion page. We are now in
the "whining" phase, so sky's the limit, add any feature you find useful
or even just kind of "cool". We will sort them out in the upcoming
"procrastinating" phase
Hello,
this message is inspired by a lot of thinking, and yesterdays talk in
#reactos, when Magnus Olsen's proposition to add support for more
than one graphic adapter was a last drop into my cup of tolerancy.
Thus I want to say, one very important idea. But what I want even
more, for our developers to understand it. The key idea is that our
work on the project now MUST be aimed at bugfixing, not at adding
even more nice features. There are already quite enough of them
(features)!
As I said 1000 times, our general "users" don't care about ability to
insert 3 graphic cards into their PC, and get ReactOS using them!
They care about ReactOS crashing after closing regedit. Or during
Office 2003 installation. And if it continues to crash this way, I'm
sorry, but noone could feel the pleasure of multiple graphic cards
support, or any other feature which is useless for 99% of potential
users.
Moreover, I don't understand why noone ever bothered to work through
the winetests for reactos-specific parts of the system, like GDI,
user32/win32k testing, kernel32 testing. There are lots of failures,
and wine test results show APIs which are used for REAL, and by REAL
applications, not some historic APIs implemented by Magnus (no
offence, I'm just using him as an example, please excuse me if I
sound harsh anywhere) which are unused by any real application nowadays.
I clearly want to stress, that there is a strong misconcept in
ReactOS way of development of its Win32 subsystem. There were a lot
of positive events happening (win32k native tests library, great work
by Timo at fixing various small issues, handles, memory leaks, etc).
But it must be continued!
Ged Murphy said very right about the problem: small problems prevent
big apps from working. Wine already supports Office 2003 for years,
and noone except me was trying to make support it better. The same
applies to everywhere, there is no need to have some special skills
to improve ReactOS. You know, there are not that many people who
*really* worked on win32k in Microsoft, and they obviously can't code
for us anyway, so everyone had to learn how to develop one or another
part of the system. Look at Stefan Ginsberg - a guy who didn't know
anything about C development 3 months ago, but learnt just by reading
ros-diffs (well, and constant private messaging me in IRC asking
questions, but that doesn't count), and yesterday spotted a couple of
important real problems.
Especially that counts for Win32-subsystem (the kernel must stay as
strict NT-alike as legally possible, so it takes time to read all
available literature), but for Win32-subsystem, just maintaining its
code would result in a hundred less crashes now! I don't even say
about rewriting bad written parts. Or just simply, very-very simply,
syncing Wine's changes back into ReactOS!
But nobody cares to do that.
I especially delay the 0.3.5 release, because I want people to
concentrate more on bugfixes. We could easily release in the
beginning of may, there are enough of good changes for a usual
reactos release. But I want this particular release to be *unusual*.
If ReactOS wants to hit beta this year, developers must concentrate
on a boring work first, believe me, there will be lots more fun when
amount of people trying out reactos increases at least 100x.
And if no beta this year, I'm sorry to say, but it may be too late.
Thanks for thorough reading. Comments are welcome.
With the best regards,
Aleksey Bragin.
Actually this change may not be enough to fix the underlying issue. I
believe there are some cases when straight calling of IoVerifyVolume
could lead to deadlock. Maybe someone can lend a helping hand here and
verify if the code is actually correct? If not I will probably get to
it myself, but it may take a few days or even weeks.
Thanks,
Filip
On Sun, May 11, 2008 at 10:04 PM, <navaraf(a)svn.reactos.org> wrote:
> Author: navaraf
> Date: Sun May 11 15:04:47 2008
> New Revision: 33449
>
> URL: http://svn.reactos.org/svn/reactos?rev=33449&view=rev
> Log:
> Fix incorrect parameters to IoSetDeviceToVerify/IoVerifyVolume. Spotted by R.T.Sivakumar <rtshiva(a)gmail.com>.
>
> Modified:
> trunk/reactos/drivers/filesystems/fastfat/create.c
>
> Modified: trunk/reactos/drivers/filesystems/fastfat/create.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa…
> ==============================================================================
> --- trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] Sun May 11 15:04:47 2008
> @@ -382,11 +382,10 @@
> DPRINT ("Media change detected!\n");
> DPRINT ("Device %p\n", DeviceExt->StorageDevice);
>
> + /* Find the device to verify and reset the thread field to empty value again. */
> DeviceToVerify = IoGetDeviceToVerify (PsGetCurrentThread ());
> -
> - IoSetDeviceToVerify (PsGetCurrentThread (),
> - NULL);
> - Status = IoVerifyVolume (DeviceExt->StorageDevice,
> + IoSetDeviceToVerify (PsGetCurrentThread (), NULL);
> + Status = IoVerifyVolume (DeviceToVerify,
> FALSE);
> }
> if (!NT_SUCCESS(Status))
>
>
This was created for all win32k/gdi32 work which is done without any
particular goal, or for directx-related work (dxeng is allowed to go
into trunk directly).
WBR,
Aleksey Bragin.
On May 11, 2008, at 3:03 PM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sun May 11 06:03:57 2008
> New Revision: 33435
>
> URL: http://svn.reactos.org/svn/reactos?rev=33435&view=rev
> Log:
> Creating a branch for Magnus Olsen's work in win32k, GDI and
> DirectX area. Finished parts will be merged back to trunk.
>
> Added:
> branches/win32k-gdi-dx/
> - copied from r33434, /
>
"DC_BITMAP or the value are not documented in MSDN or ms header" ...
and that's precisely why the definition belongs to another (internal)
header file and not here.
F.
On Sat, May 10, 2008 at 7:37 PM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Sat May 10 12:37:43 2008
> New Revision: 33411
>
> URL: http://svn.reactos.org/svn/reactos?rev=33411&view=rev
> Log:
> adding a new define DC_BITMAP for GetStockObject
>
> Modified:
> trunk/reactos/include/psdk/wingdi.h
>
> Modified: trunk/reactos/include/psdk/wingdi.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/wingdi.h?rev=…
> ==============================================================================
> --- trunk/reactos/include/psdk/wingdi.h [iso-8859-1] (original)
> +++ trunk/reactos/include/psdk/wingdi.h [iso-8859-1] Sat May 10 12:37:43 2008
> @@ -813,6 +813,12 @@
> #define SYSTEM_FONT 13
> #define SYSTEM_FIXED_FONT 16
> #define DEFAULT_PALETTE 15
> +
> +/* NOTE DC_BITMAP or the value are not documented in MSDN or ms header
> + * it return a 1x1 1Bpp Bitmap in all case from GetStockObject
> + */
> +#define DC_BITMAP 21
> +
> #if (_WIN32_WINNT >= 0x0500)
> #define DC_BRUSH 18
> #define DC_PEN 19
>
>
Hi devs,
I don't think this patch should be refused, what about "Shell32 improvements" in: http://www.reactos.org/en/newsletter_34.html?
And all the commits made recently by johannes (also in shlview.c)? After almost a year we close the bug saying it's not our code?
WBR
Gabriel ilardi.
> Date: Fri, 9 May 2008 18:13:49 +0200> From: ReactOS.Bugzilla(a)www.reactos.org> To: ros-bugs(a)reactos.org> Subject: [ros-bugs] [Bug 644] directional keys problem with Explorer> > http://www.reactos.org/bugzilla/show_bug.cgi?id=644> > > amine48rz <amine48rz(a)gmail.com> changed:> > What |Removed |Added> ----------------------------------------------------------------------------> Status|NEW |ASSIGNED> Status|ASSIGNED |NEW> CC| |amine48rz(a)gmail.com> AssignedTo|info(a)w3seek.de |johannes.anderwald(a)student.t> | |ugraz.at> > w3seek <w3seek(a)reactos.com> changed:> > What |Removed |Added> ----------------------------------------------------------------------------> CC| |w3seek(a)reactos.com> Status|NEW |RESOLVED> Resolution| |WONTFIX> > > > > --- Comment #3 from w3seek <w3seek(a)reactos.com> 2008-05-09 18:13:48 CET ---> (In reply to comment #2)> > Created an attachment (id=1341)> --> (http://www.reactos.org/bugzilla/attachment.cgi?id=1341) [details]> > LISTVIEW_GetNextItem Patch> > Here's a new patch for which i rewrote the LISTVIEW_GetNextItem routine, so> > that the ListView itself is aware of whether LVS_ALIGNTOP or LVS_ALIGNLEFT is> > set and returns the correct next item.> > But I still like the other patch just because I dislike scrolling horizontal in> > a list :).> > This patch should not be accepted for ReactOS. This is code shared with WINE> and needs to be submitted to winehq.> > > -- > Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email> ------- You are receiving this mail because: -------> You are the QA contact for the bug.> _______________________________________________> Ros-bugs mailing list> Ros-bugs(a)reactos.org> http://www.reactos.org/mailman/listinfo/ros-bugs
_________________________________________________________________
Crea il tuo blog su Spaces, condividi le tue esperienze con il mondo!
http://home.services.spaces.live.com/
Hi everybody,
I tracked down the Explorer startup crash we experience since r33366 and
came to some weird results.
First of all, this crash also occurs when testing under Windows. Also
Explorer runs well when it's compiled with MSVC using the supplied
"explorer.sln" file.
Then I put MessageBoxes to some code pathes to track down, where the crash
occurs.
The weird thing is: It fails in the IconCache code (which doesn't even
handle strings, so shouldn't be affected by Unicode at all).
Just put a MessageBox at explorer.cpp:389 and then after _icons[ICID_NONE]
was assigned. You will see that the second message box won't appear.
You can also put a MessageBox in the Icon constructor, it won't be shown
either.
So what's going wrong here?
Bug in our mingw startup routine, memory corruption, bug in gcc, ...? I'm
out of ideas.
Best regards,
Colin
Hi folks,
I'd like to try Reactos in Xen. Is there any image available ?
thx
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
On Tue, May 6, 2008 at 12:15 PM, <gbrunmar(a)svn.reactos.org> wrote:
> + if (IsBadWritePtr(pMode, sizeof(D3DDISPLAYMODE*)))
Is this really a good idea?
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Just to clarify to anyone following this thread, the change from SystemParametersInfo to sending a message isn't incorrect.
kbswitch is meant to be a sort of makeshift ctfmon.exe, and isn't meant for switching keyboards system-wide as intl.cpl does.
The buffer overflow problems still stand though.
Ged.
> -----Original Message-----
> From: gedmurphy [mailto:gedmurphy@gmail.com]
> Sent: 22 April 2008 21:03
> To: 'ros-dev(a)reactos.org'
> Subject: RE: [ros-diffs] [dchapyshev] 33106: - Keyboard layout
> switching works now in ReactOS!
>
> dchapyshev(a)svn.reactos.org wrote:
> >
> > Author: dchapyshev
> > Date: Tue Apr 22 14:01:56 2008
> > New Revision: 33106
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=33106&view=rev
> > Log:
> > - Keyboard layout switching works now in ReactOS!
>
>
> Hi, just a few points about this patch.
>
>
> > + if (RegOpenKeyEx(HKEY_CURRENT_USER, _T("Keyboard
> > Layout\\Substitutes"), 0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS)
> > + {
> > + dwBufLen = MAX_PATH;
> > +
> > + if (RegQueryValueEx(hKey, szTempLCID, NULL, NULL,
> > (LPBYTE)szLCID, &dwBufLen) != ERROR_SUCCESS)
>
>
> Firstly, Reg functions work on bytes, so you introduced a potential
> buffer overflow here.
> But this is irrelevant due to the next point ;)
>
>
> > - Ret = SystemParametersInfo(SPI_SETDEFAULTINPUTLANG, 0, &hKl,
> > SPIF_SENDWININICHANGE);
> > + EnumWindows(EnumWindowsProc, (LPARAM) hKl);
>
>
> This looks like a hack. The original method was correct, it just need
> implementing in win32k.
> Have a look in NtUserSystemParametersInfo.
>
> Thirdly, what is this kbswitch app? It's not a standard windows tool,
> yet it's included in our base.
> Keyboard switching is done in intl.cpl, or via ctfmon (which we don't
> yet have) on a per app basis.
>
> Regards,
> Ged.
dchapyshev(a)svn.reactos.org wrote:
>
> Author: dchapyshev
> Date: Tue Apr 22 14:01:56 2008
> New Revision: 33106
>
> URL: http://svn.reactos.org/svn/reactos?rev=33106&view=rev
> Log:
> - Keyboard layout switching works now in ReactOS!
Hi, just a few points about this patch.
> + if (RegOpenKeyEx(HKEY_CURRENT_USER, _T("Keyboard
> Layout\\Substitutes"), 0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS)
> + {
> + dwBufLen = MAX_PATH;
> +
> + if (RegQueryValueEx(hKey, szTempLCID, NULL, NULL,
> (LPBYTE)szLCID, &dwBufLen) != ERROR_SUCCESS)
Firstly, Reg functions work on bytes, so you introduced a potential buffer overflow here.
But this is irrelevant due to the next point ;)
> - Ret = SystemParametersInfo(SPI_SETDEFAULTINPUTLANG, 0, &hKl,
> SPIF_SENDWININICHANGE);
> + EnumWindows(EnumWindowsProc, (LPARAM) hKl);
This looks like a hack. The original method was correct, it just need implementing in win32k.
Have a look in NtUserSystemParametersInfo.
Thirdly, what is this kbswitch app? It's not a standard windows tool, yet it's included in our base.
Keyboard switching is done in intl.cpl, or via ctfmon (which we don't yet have) on a per app basis.
Regards,
Ged.
Any real explanation in the commit message about what was done in this
commit? Short, real and clean, so every developer reading the commit
messages could understand what was done and why.
I'm suspicious that it "fixes" one bug, and reopens another.
The same note applies to "start kill the bad macro DXG_GET_INDEX_FUNCTION
that is instable" (rev. 33012). Macro is a preprocessor definition, it can't
be stable or not, it's being performed before the actual compile stage.
Better to explain while enumerating through all functions to find the best
one is worse than just getting a pointer by indexing. Or why it was done so
in the beginning.
With the best regards,
Aleksey Bragin.
----- Original Message -----
From: <greatlrd(a)svn.reactos.org>
To: <ros-diffs(a)reactos.org>
Sent: Friday, April 18, 2008 4:56 AM
Subject: [ros-diffs] [greatlrd] 33014: fixed pipe working again from cmd
more investigate are need it to figout who to really solv bat and pipe and
gui apps issue so none regress and working fine in all case. rember gui apps
can resive pipe from cmd or send to cmd
> Author: greatlrd
> Date: Thu Apr 17 19:56:01 2008
> New Revision: 33014
>
> URL: http://svn.reactos.org/svn/reactos?rev=33014&view=rev
> Log:
> fixed pipe working again from cmd
> more investigate are need it to figout who to really solv bat and pipe and
> gui apps issue
> so none regress and working fine in all case. rember gui apps can resive
> pipe from cmd or send to cmd
Hello ROS dev-team,
i am currently working on qemu/kqemu and found that ROS sets the gdt
limit to 0x800. At least this is what i see in qemu, i did not check
ROS source.
http://www.intel.com/design/processor/manuals/253668.pdf (3.5.1 p. 3-21)
>> the GDT limit should always be one less than an integral multiple of
>> eight (that is, 8N – 1)
This may or may not be a problem.
For all i can say ROS was the only of many different OSs that triggered
the check in my setup. I may be wrong and wont investigate this any
further. Just wanted to let you know.
I used this version:
http://prdownloads.sourceforge.net/reactos/ReactOS-0.3.4-REL-qemu.zip
and that are the values i saw:
base = 0x808bdac0
limit = 0x00000800
regards,
Henning
Hi Team,
I came across this site: http://www.acc.umu.se/~bosse/
which has some windows drivers examples, and talks about filesystem
drivers, it has a gnu version of ntifs.h (http://www.acc.umu.se/~bosse/ntifs.h), I've taken a look at it, and
noticed that ours misses some defines and some definitions use other types instead of
ours. I thought perhaps someone from the team would want to take a look
at it, perhaps we could use it.
Thanks.
Best regards,
Gabriel ilardi.
PS: If you already knew about it please ignore this email.
_________________________________________________________________
Racconta le tue emozioni sul blog!
http://home.services.spaces.live.com/
Fireball, could you commit the bug writing guidelignes change to avoid this, please ?
*saying Pleaase ... Help as Milla Jovovitch in the Fifth Element*
Kind regards,Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net
----- Message d'origine ----
> De : "ReactOS.Bugzilla(a)www.reactos.org" <ReactOS.Bugzilla(a)www.reactos.org>
> À : ros-bugs(a)reactos.org
> Envoyé le : Samedi, 12 Avril 2008, 22h08mn 14s
> Objet : [ros-bugs] [Bug 3177] New: I try ReactOS-0.3.4-QEMU. When i try screensaver it gives bluescreen
>
> http://www.reactos.org/bugzilla/show_bug.cgi?id=3177
>
> Summary: I try ReactOS-0.3.4-QEMU. When i try screensaver it
> gives bluescreen
> Product: ReactOS
> Version: 0.3.4
> Platform: QEmu
> OS/Version: Microsoft Windows XP
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: Win32
> AssignedTo: ros-bugs(a)reactos.org
> ReportedBy: maviates(a)gmail.com
> QAContact: ros-bugs(a)reactos.org
>
>
> Created an attachment (id=2431)
> --> (http://www.reactos.org/bugzilla/attachment.cgi?id=2431)
> BlueScreen
>
> I try ReactOS-0.3.4-QEMU. When i try screensaver it gives bluescreen
>
>
> --
> Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug.
> You are the assignee for the bug.
> _______________________________________________
> Ros-bugs mailing list
> Ros-bugs(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-bugs
>
I thought those are on auto-winesync, aren't they? If you come to agreement
with Herve, I don't mind.
But anyway, Apostolos should submit those translation updates to Wine
project.
WBR,
Aleksey Bragin.
----- Original Message -----
From: <cfinck(a)svn.reactos.org>
To: <ros-diffs(a)reactos.org>
Sent: Friday, April 11, 2008 1:00 AM
Subject: [ros-diffs] [cfinck] 32909: Manually sync "comctl32" and "comdlg32"
on request of Apostolos Alexiadis. Just translation updates
> Author: cfinck
> Date: Thu Apr 10 16:00:16 2008
> New Revision: 32909
>
> URL: http://svn.reactos.org/svn/reactos?rev=32909&view=rev
> Log:
> Manually sync "comctl32" and "comdlg32" on request of Apostolos Alexiadis.
> Just translation updates
>
> Modified:
> trunk/reactos/dll/win32/comctl32/comctl_El.rc
> trunk/reactos/dll/win32/comctl32/comctl_Si.rc
> trunk/reactos/dll/win32/comdlg32/cdlg_El.rc
> trunk/reactos/dll/win32/comdlg32/cdlg_No.rc
> trunk/reactos/dll/win32/comdlg32/cdlg_Si.rc
I looked at the ReactOS website and noticed that you guys are having
problems getting an installer written for an ext2 driver for Windows XP? I
would be happy to write an NSIS-based installer for the ext2 driver, if
either someone could compile the driver for me, or tell me where the driver
is in the ReactOS tree so I can build it myself and create an installer for
it. I have written NSIS installers before, some that have advanced
functionalities using Component Manager and ExperienceUI. Please let me know
if you guys would like me to make this installer....
I am currently trying to clean up our win32k headers.
The situation so far:
- ntgdi.h in psdk which should be compatible to ms version of ntgdi.h
from the sdk
- ntgdytyp.h containing a bunch of gdi related types in
include/reactos/win32k
- ntgdihdl.h containing handle related types and macros in
include/reactos/win32k
- ntgdibad.h containing private and ms incompatible functions and
structures in include/reactos/win32k
- ntuser.h containing ntuser functions and types in include/reactos/win32k
- ntusertyp.h containing ntuser related types in include/reactos/win32k
- W32CLIENTINFO is defined in both ntusertyp.h and ntgdityp.h (less
complete).
- there is the PATRECT structure in ntuser.h, and if ntuser.h is not
included, also in ntgdityp.h, this should be named POLYPATBLT as defined
in ntgdi.h, but there is only an incomplete type without the structure
definition. (IMO ms should have put this structure into wingdi.h
together with PolyPatBlt, but they don't seem to want anyone use that
gdi32 exported function.)
I wonder why ms put ntgdi.h into the sdk at all, as it's completely
useless to user mode application writers, but well, ncie to have the
prototypes ;-)
So how do we clean up this mess?
Suggestions:
- when ms puts ntgdi.h into the sdk, we could also put ntuser.h there.
- if we want to stay 100% compatible with sdk headers, we can add a
define, like
#ifdef USE_NON_SDK
// put non sdk compatible but still windows compatible definitions here
#endif
- use a version definition, like I did with the simplecall definitions
in ntuser.h to make it compatible to different windows versions
- keep ntgdibad.h and create ntuserbad.h for incompatible definitions
- ntgdihdl.h is used by win32k and gdi32, both also import ntgdityp.h.
So I'd suggest merging that stuff into ntgdityp.h
- maybe merge types into ntgdi.h and ntuser.h? Some definitions are
already in there.
- create win32ktypes.h and put ntuser/ntgdi shared stuff there, like
W32CLIENTINFO
- maybe add POLYPATBLT and PolyPatBlt() (others?) to wingdi.h inside
USE_NON_SDK ifdef plus a POLYPATBLT_DEFINED
I don't think it's a problem to make our sdk headers more complete than
ms ones. This might help if we don't want a header mess or extra
definitions inside the .c files.
Comments appreciated.
Thanks,
Timo
Hi!
Thank you Timo, I can not believe I missed this one....
This fixes a commit back at rev 14041.
With out starting a review in real world history,, once an enemy gains
control the first thing they do is erase history. New eras evolve and
build on top of old ones. Our old world ruins are a good example. Look
at Cuzco, Greece and Rome. You see them now uncovering the past.
Thanks again!
James
SepCreateSystemProcessToken calls ObCreateObject like this:
Status = ObCreateObject(KernelMode,
SepTokenObjectType,
NULL,
KernelMode,
NULL,
sizeof(TOKEN),
0,
0,
(PVOID*)&AccessToken);
the ObjectAttributes parameter is set to NULL,and ObCreateObject passes
ObjectAttributes to call ObpCaptureObjectAttributes like this:
Status = ObpCaptureObjectAttributes(ObjectAttributes,
ProbeMode,
FALSE,
ObjectCreateInfo,
&ObjectName);
and in ObpCaptureObjectAttributes ,there's a check condition that checks if
ObjectAttributes is NULL, if ObjectAttributes is NULL,it will cause
ObpCaptureObjectAttributes fail,and then cause ObCreateObject fail,then
cause SepCreateSystemProcessToken fail,and the return value of
SepCreateSystemProcessToken will ever be NULL.
Could someone explain why???am i wrong??
While installing and using ReactOS 0.34 (on Windows XP Professional with
VmWare Workstation 6.03) I'm experiencing a couple of issues.
- Are there any new requirements to install ReactOS? 586+ with 64MB for
example instead of earlier 486+/16MB ?
- Are there any new requirements to bootup ReactOS? 586+ with 64MB?
would/should swapfile work with lower amount of system memory installed
on the machine?
- Are there any new requirements to use ReactOS? 586+ with 64MB? Does
swapfile work?
- Is commandline-only supported on machines with not enough memory
installed?
Ofcourse booting from CD has to be supported on the target machine,
either natively or through tricks like Smart Boot Manager or
GRUB(-4-DOS) (or FreeLDR even?).
The actual trouble I'm having is completing 0.34's installation process
with Dutch language and USA keyboard layout (which isn't default, you
seem to prefer Belgium keyboard layout by default, which might be just
as strange as a Dutch keyboard layout by default. Those keyboards hardly
exist at all). It seems to hang on this machine at a random moment of
time during the file copy phase. In the end, I cannot install FreeLDR to
diskette (empty WinImage 1.44MB diskette image), nor can I return to
previous screen to select "install to harddisk". My goal was having a
FreeLDR bootdisk in case I mess up the partition bootsector.
Anyway, using English as installation language and its defaults, I can
complete SETUP properly. While in ReactOS booted from harddisk, opening
a simple console window (CMD) and doing DIR A: results in a blue screen
(instead of a message like "no floppydrive installed") Same issue as
known earlier I guess - non-working floppydrive(r).
My old FreeLoader diskette is based on a FreeLDR bootdisk that Casper
Hornstrup(?) had available at the time. It's available from
http://odin.fdos.org/odin2005/
Booting the diskette, pressing CTRL-C, then doing a simple COPY /Y
C:\FREELDR.SYS A:\FREELDR.SYS does the trick for updating FreeLDR from
2.xx to 3.xx, resulting in being able to boot ReactOS 0.34 from a
diskette. Strangely enough no single DOS tool/command can handle
FREELDR.INI (copy, ren, del, edit, all fail) - any idea why?
Last of all, SHUTDOWN doesn't shut off the computer (guess you want to
be sure everything in cache is flushed?), and LOGOFF won't allow me to
get out of entering my username and password.
Looking forward to a ReactOS with OpenOffice and FireFox 3.xx in a while,
Any help, ideas or recommendations much appreciated (as well as pointing
me to the correct mailinglist if it shouldn't be ros-dev)
Bernd Blaauw
As we know Windows (at least till Windows 7) was designed to be a GUI based
operating system. All applications can safely assume that the windowing
subsystem is running.
Windows/Reactos can run native applications without starting the windowing
subsystem like usetup during 1st stage setup but of course without having
access to Win32 apis as Win32k is not loaded. AFAIK win32k is designed to be
the main subsystem and is the responsible of starting the windowing
subsystem so my question is . Would be technically possible to have a
striped win32k version without the GUI code? + command line enabled
winlogon, syssetup etc.. so you can boot and run cli based applications like
cmd.exe ? what other parts of the boot process relay on having the GUI
running?
It's more of a design curiosity question rather than a real request
Regards,
Marc
With regards to Tsonic OS,
It would be very advisable at this point to get all DNS information
and ISP information and report this individual(s) to either their ISP
or Fairview, or perhaps both.
--
-David W. Eckert
Two things:
1) Please take me off your list. I know that you pulled
my email address from the reactos mailing list. Since
your project is not reactos, I'm not interested in hearing
about it.
2) Posting links to leaked Microsoft source code in any
forum related to reactos shows a complete lack of good
judgment, and a lack of knowledge of recent reactos
history. I certainly hope that you don't intend to try to
check a derivative of leaked Windows source into the
reactos tree. That would taint reactos and make it
vulnerable to legal action (at least here in the US).
Further, since you are acting as a spokesperson for
TonicOs, and are passing around links to stolen Microsoft
intellectual property, I would consider TonicOs already
tainted. Please take conversations about leaked Windows
source to some other venue.
--mark
On Wed, 12 Mar 2008 12:44:18 -0800
"Tsvetan Banchev" <tsvetanmail(a)gmail.com> wrote:
> http://[cut]/Windows_2000_source_code
> http://[cut]/Windows_XP_Source_Code
> obtained from a friend inside ms ;)
>
> rar password needs cracking, working on it now. could
>take a few days. if
> anyone's got a high end machine it'd be appreciated if
>they could use a RAR
> password recovery app to get it.
Hi,
On Wed, Mar 12, 2008 at 2:07 PM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Wed Mar 12 14:07:32 2008
> New Revision: 32667
>
> URL: http://svn.reactos.org/svn/reactos?rev=3D32667&view=3Drev
> Log:
> - Fix build.
>
> Modified:
> trunk/reactos/ntoskrnl/ntoskrnl-generic.rbuild
>
> Modified: trunk/reactos/ntoskrnl/ntoskrnl-generic.rbuild
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ntoskrnl-gen=
> eric.rbuild?rev=3D32667&r1=3D32666&r2=3D32667&view=3Ddiff
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D
Diffs have been broken since the recent email problems. Is there any
estimate on when/if this is going to be fixed?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Why did that big chunk of MS's support database text got into our
codebase? Even not edited, so that I can read up about "tax form 1040
would not print correctly" in ReactOS Source code? What is the use
from it?
If you wanted SO MUCH, you could at least edit it, or ask someone to
edit it for you (we have quite a few people in our team). But then, I
could insert half of WDK docs into the kernel source code and drivers
source code (which in fact would violate copyrights, since it would
not even be fair use).
Providing URL is quite enough, though, if I don't mistake (I'm not up
to date with their position), Wine is already removing URLs from
source code because they should be kept somewhere else. Source code
is source code, not a collector to store everything. There is no
point in sticking various garbage into reactos source code with a
note "so it doesn't get lost", we've come over that point quite a few
years ago.
With the best regards,
Aleksey Bragin.
On Mar 11, 2008, at 3:09 AM, greatlrd(a)svn.reactos.org wrote:
> Author: greatlrd
> Date: Mon Mar 10 19:09:23 2008
> New Revision: 32652
>
> URL: http://svn.reactos.org/svn/reactos?rev=3D32652&view=3Drev
> Log:
> part 2/2 for implement GetAppCompatFlags
> left todo implemented set AppCompatFlags =
>
>
> Modified:
> trunk/reactos/dll/win32/user32/misc/stubs.c
>
> + /* NOTE : GetAppCompatFlags retuns which compatible flags should
> be send=
> back =
>
> + * the return value is any of http://support.microsoft.com/kb/82860
> + * This text are direcly copy from the MSDN URL, so it does not
> get lost
> +
> *---------------------------------------------------------------------
> -=
> --------
> + * Bit: 1
Lots of text here
> + =
>
> + return ti->dwAppsCompatibleFlags;
> }
> =
>
> /*
Hi,
after r32615 and r32623, I send you this mail in order to find some volunteers to remove all remaining $id from files and also to update FSF address in files hearders.
Thanks in advance to the volunteers.
Best regards,
P. Schweitzer
Hiya,
I have a GPLed driver using the WDF. I'm not clear on the legal status
of redistributing GPLed source compiled with the Windows DDK so I'd like
to try MinGW.
After Googling, I see a couple of mentions back in 2004 that "WDF will
have to be supported eventually" but nothing since then? Am I correct in
assuming if I want to use MinGW, WDF cannot be used?
Thanks -- Andy
Hello,
today all servers (web, svn, mailing lists, etc) will most probably
be unavailable for an undetermined amount of time, due to IP
addresses change by the hosting company.
They beg their pardon for the unconvinience.
With the best regards,
Aleksey Bragin.
IopFreeIoCompletionPacket has the opposite bug -- there is an
interlocked push (free) even in the ExFreePool case. There should be a
return following the ExFreePool, otherwise we're corrupting memory.
On Thu, Feb 28, 2008 at 11:37 AM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Thu Feb 28 14:37:14 2008
> New Revision: 32521
>
> URL: http://svn.reactos.org/svn/reactos?rev=32521&view=rev
> Log:
> - Fix leaking an entry in some cases during ObpFreeCapturedAttributes call. For more details: http://www.reactos.org/forum/viewtopic.php?t=5311.
>
> Modified:
> trunk/reactos/ntoskrnl/include/internal/ob_x.h
>
> Modified: trunk/reactos/ntoskrnl/include/internal/ob_x.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/include/internal/ob_x.h (original)
> +++ trunk/reactos/ntoskrnl/include/internal/ob_x.h Thu Feb 28 14:37:14 2008
> @@ -290,6 +290,12 @@
> List->L.FreeMisses++;
> List->L.Free(Buffer);
> }
> + else
> + {
> + /* The free was within the Depth */
> + InterlockedPushEntrySList(&List->L.ListHead,
> + (PSINGLE_LIST_ENTRY)Buffer);
> + }
> }
> else
> {
>
>
>
--
Best regards,
Alex Ionescu
On Fri, Feb 22, 2008 at 7:14 AM, <mpiulachs(a)svn.reactos.org> wrote:
> Author: mpiulachs
> Date: Fri Feb 22 15:14:08 2008
> New Revision: 32449
>
> URL: http://svn.reactos.org/svn/reactos?rev=32449&view=rev
> Log:
> Add support for multiple architectures to autorun.inf
>
> Modified:
> branches/rbuild/reactos/boot/bootdata/autorun.inf
>
> Modified: branches/rbuild/reactos/boot/bootdata/autorun.inf
> URL: http://svn.reactos.org/svn/reactos/branches/rbuild/reactos/boot/bootdata/au…
> ==============================================================================
> --- branches/rbuild/reactos/boot/bootdata/autorun.inf (original)
> +++ branches/rbuild/reactos/boot/bootdata/autorun.inf Fri Feb 22 15:14:08 2008
> +[autorun.mips]
> +
> +open=mips\welcome.exe
> +icon=icon.ico
> +
> +[autorun.alpha]
> +
> +open=alpha\welcome.exe
> +icon=icon.ico
This is really unneeded. Alpha is one nail away from the coffin being
closed and nobody is even remotely interested in doing a mips port
right now. Please remove them and add a an arm entry.
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
This should be a simple one to fix. I can build the rest of the tree
and make bootcd works
CC] lib/cmlib/cminit.c
lib/cmlib/cminit.c:22:15: error: attempt to use poisoned "wcslen"
lib/cmlib/cminit.c: In function 'CmpPrepareIndexOfKeys':
lib/cmlib/cminit.c:98: warning: implicit declaration of function 'DbgPrint'
mingw32-make: *** [obj-i386/lib/cmlib_host/cminit.o] Error 1
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
I've not had a chance to dig in and see which changeset caused the
issue but since the recent bringup changes I can no longer use the
bootcd on Parallels.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
The off-by-one errors are because MmPageArraySize is:
MmPageArraySize = MmHighestPhysicalPage;
and not
MmPageArraySize = MmHighestPhysicalPage + 1;
Just my 2 cents,
Pablo
On Fri, 15 Feb 2008, ros-arm-bringup(a)svn.reactos.org wrote:
> Author: ros-arm-bringup
> Date: Fri Feb 15 04:04:22 2008
> New Revision: 32371
>
> URL: http://svn.reactos.org/svn/reactos?rev=32371&view=rev
> Log:
> Fixed several off-by-one errors when playing with the PFN database array size. Among other things, certain valid pages would be considered invalid, and also the PFN database wouldn't be properly erased on startup (which would result in a crash after a warm reboot or restarting the emulator).
>
> Modified:
> trunk/reactos/ntoskrnl/mm/freelist.c
On Feb 12, 2008 3:32 PM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> Author: ros-arm-bringup
> Date: Tue Feb 12 23:32:23 2008
> New Revision: 32333
>
> URL: http://svn.reactos.org/svn/reactos?rev=32333&view=rev
> Log:
> Added cache sweeping code into the HAL, for ARM926EJ-S and ARM1026EJ-S CPUs.
> Finished implementation of KiSystemStartup.
> Copied KiInitializeKernel from x86 to ARM, removing irrelevant parts. This is our current checkpoint.
Is there an offical bringup toolchain posted somewhere or steps on how
to build one from the RosBE sources?
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi!
My best guess is http://gnuarm.org/
I have no idea of anything else.
Thanks,
James
On Feb 12, 2008 5:30 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
> On Feb 12, 2008 3:32 PM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> > Author: ros-arm-bringup
> > Date: Tue Feb 12 23:32:23 2008
> > New Revision: 32333
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=32333&view=rev
> > Log:
> > Added cache sweeping code into the HAL, for ARM926EJ-S and ARM1026EJ-S CPUs.
> > Finished implementation of KiSystemStartup.
> > Copied KiInitializeKernel from x86 to ARM, removing irrelevant parts. This is our current checkpoint.
>
> Is there an offical bringup toolchain posted somewhere or steps on how
> to build one from the RosBE sources?
>
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
2008/2/12, Gregor Brunmar <gbrunmar.ros(a)gmail.com>:
> Sounds like a cool feature, I'm waiting for it eagerly :)
The new ReactOS People Map can be found there:
http://www.reactos.org/peoplemap/
Klemens
Sounds like a cool feature, I'm waiting for it eagerly :)
-Gregor
cfinck(a)svn.reactos.org wrote:
> Author: cfinck
> Date: Mon Feb 11 21:43:40 2008
> New Revision: 32303
>
> URL: http://svn.reactos.org/svn/reactos?rev=32303&view=rev
> Log:
> New ReactOS People Map based on Google Maps API (not yet on the Web server)
>
> The map integrates into the existing website and is linked with the RosCMS accounts.
> You can add a group of users (like Translators, Developers, Administrators, etc.) to the map or search for people and add them individually. I made tests with 500 random users on one map and it was still usable :-)
> Also there are easy features for setting your own position.
>
> I successfully tested the People Map with Firefox 2.0, Opera 9.21, Safari 3 Beta, Konqueror 3.5.6 and IE6/7.
> The marker graphics were done myself with Inkscape and the other graphics were composed out of icons from the Tango Icon Project or taken from other ReactOS web apps.
> The PNGs with alpha transparency are also shown correctly under IE6 using a trick in "ie6-fixes.css".
>
>
Even more, I think it was you who implemented this entrypoint in the
ReactOS kernel :-).
I'll discuss with PPC and ARM ports, and then we could make a switch
alltogether.
WBR,
Aleksey Bragin.
On Feb 12, 2008, at 5:56 PM, Alex Ionescu wrote:
> Actually, I've never heard of the entrypoint being called
> NtProcessStartup for the kernel...
>
> Why not fix the name in the x86 sources?
Actually, I've never heard of the entrypoint being called
NtProcessStartup for the kernel...
Why not fix the name in the x86 sources?
On 12-Feb-08, at 8:34 AM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Tue Feb 12 16:34:33 2008
> New Revision: 32321
>
> URL: http://svn.reactos.org/svn/reactos?rev=32321&view=rev
> Log:
> - Kernel's entrypoint is called NtProcessStartup right now, for
> ReactOS. If this is to be changed, it should be changed for all
> archs, not only for ARM.
>
> Modified:
> trunk/reactos/tools/rbuild/module.cpp
>
> Modified: trunk/reactos/tools/rbuild/module.cpp
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/module.cpp?re…
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- trunk/reactos/tools/rbuild/module.cpp (original)
> +++ trunk/reactos/tools/rbuild/module.cpp Tue Feb 12 16:34:33 2008
> @@ -1033,7 +1033,7 @@
> switch ( type )
> {
> case Kernel:
> - return "KiSystemStartup";
> + return "NtProcessStartup";
> case KernelModeDLL:
> case KernelModeDriver:
> return "DriverEntry@8";
>
>
Best regards,
Alex Ionescu
I wonder why those functions spread around that much (cacls, sndvol, aclui, servman, etc...), since windows has already the needed function:
LoadString will store a pointer to the string resource in *lpBuffer, if nBufferMax is set to 0, so allocating additional memory is not neccessary in most cases. And it also returns the full length.
http://msdn2.microsoft.com/en-us/library/ms647486(VS.85).aspx
>
> Author: cfinck
> Date: Sat Feb 2 00:40:18 2008
> New Revision: 32079
>
> URL: http://svn.reactos.org/svn/reactos?rev=32079&view=rev <http://svn.reactos.org/svn/reactos?rev=32079&view=rev>
> Log:
> Wrote a Win32 Font Editor for our VGA Fonts used in blue.sys.
>
> It has a MDI user interface, imports binary fonts (.bin) and PC Screen Fonts (.psf) and exports .bin fonts.
> Compiles without any warnings with GCC and MSVC (at /W3).
>
> The "misc.c" file was taken from devmgmt (thanks Ged!) and modified.
>
>
Hi!
Somehow NtUserGetWindowThreadProcessId was moved to the main list.
This is wrong! With in the next six months
NtUserGetWindowThreadProcessId (unless it was added in Vista) and
friends will no longer be in ReactOS. Please do not create more work
than it is necessary to accomplish this rewrite.
-# ReactOS only system calls
-NtUserAcquireOrReleaseInputOwnership 1
-NtUserGetWindowThreadProcessId 2
-NtUserGetQueueStatus 1
Thanks,
James
Hello
I want port some function from wine kernel32.dll to ReactOS
kernel32.dll but have some problems.
First i have two modules and the question is where is the right place
to put them.
I need /tools/unicode/wctype.c also here /dll/win32/kernel32/misc/ to
compile.
1.) Is it better to leave this module in /tools/unicode/ ?
-> What must i write in kernel32.rbuild to build this module
with kernel32.dll
2.) or copy this file to /dll/win32/kernel32/misc/
the second solution is a bit ugly because we have tow files whit the
same contents.
3.) ???
thanks
Daniel
________________________________________________________________________
More new features than ever. Check out the new AIM(R) Mail ! -
http://webmail.aim.com
Alex wrote:
>On 26-Jan-08, at 2:34 PM, Marc Piulachs wrote:
>
>> Hi,
>>
>> I'm not very sure about r32018-r32022.
>>
>> Some compiler warnings are stupid and useless, some others not.
>
>This one is stupid.
Actually, I'd say the stupidity is in using a runtime assert, when a
compile-time assert will do the trick (not using CPU at runtime, while
enforcing the condition).
Unless memory fails me, in C++ you can implement ct_assert(x) like:
typedef char[x!=0] foo;
as an array of size zero is an error.
How does current C compilers react to typedefs of zero-sized arrays?
Sure, one can't use it exactly as in C++, but it could still be useful
to at least know about this idiom.
Problems should be trapped as early as possible.
--
Mike
>
> I think the "fixme" in halx86/mp/apic.c line 583 is no need to fix,i have
> > read the linux source code ,which just configure like reactos.So still
> > need to fix?
>
>
>
when we use iocp,first,we should create a port like
this --- CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);---
But in the implementation of CreateIoCompletionPort,the beginning of the
fuction is :
if ( ExistingCompletionPort == NULL && FileHandle == INVALID_HANDLE_VALUE
)
{
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
}
so ,all the application running well on MS Windows will not run correct in
ReactOS,Because they will always get the ERROR_INVALID_PARAMETER error code
when they
call CreateIoCompletionPort like
--CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);--
I think this is a problem,But I'm not sure!
Hello,
it's not really completely supported now.
As for the label, it was a typo, and I fixed it in revision 31882.
WBR,
Aleksey Bragin.
On Jan 19, 2008, at 12:48 PM, Xiaoming Gao wrote:
> Hello everyone
> I'm a new comer,i'm reading the kernel source ,but i found that
> "jz NotBusy " in ctxswitch.S (line 351),the NotBusy label is not
> defined.I have searched the whole source code,but not found it. So,
> would someone tell me some information about this?
Hello everyone
I'm a new comer,i'm reading the kernel source ,but i found that "jz
NotBusy " in ctxswitch.S (line 351),the NotBusy label is not defined.I have
searched the whole source code,but not found it. So, would someone tell me
some information about this?
> 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
Hi list,
attached is a patch that updates our msiexec from the wine sources. From
what I can tell it has 2 major changes:
- option handling is now much more sane (no "if (!xyz)" but "if (xyz)")
- addition of argument "/regserver"
I also added the icon from wine for msiexec. Not sure if it's ok. Tell
me if I should create another (if someone tells me how the icon should
look like I would do a better one).
Regards,
Christoph Brill
I would like to ask if usrmgr is open for translation. As Eric Kohl left the
following message inside en-US.rc:
* Attention Translators:
* DO NOT TRANSLATE THESE RESOURCES YET!
it should be quite evident, its not ready yet.
Alas, a russian translation exists, commited by Fireball himself.
Regards
Olaf Siejka aka Caemyr aka Haos
I get an error while trying to install Firefox 2.0 on a bootcd
compilation, finally i found the possibly bug is in vfatfs.sys i
modified some lines but is not my code.....it seems to install Firefox.
Also, testing firefox i found problems with gdi and also done some
modifications, still testing them..
Here is my patch..NO WARRANTY he he..
Basically, Oriol just uncommented your #if0-ed code, and substituted
SEH-wrapped pointer operation with a worse "if not null" check. And
that's filtering a number of unrelated debug-messages hacks.
But, Oriol, you're giving good signs you're improving! :-) The VFAT
problem of not clearing the delete pending flag is a good thing
(Christoph discovered that, however there are still problems if you
clear the flag).
With the best regards,
Aleksey Bragin.
On Jan 4, 2008, at 10:46 AM, James Tabor wrote:
> Hi,
> I can only write about the gdi code changes.
>
> 1st dll/win32/gdi32/misc/misc.c looks good!
> 2nd the dc.c changes,,, ATM the support code for dirty bit sets is not
> inplace, but the patch is good.
>
> I will apply your patch ASAP for the GDI changes, it does look good.
>
> Thanks,
> James
>
> On Jan 3, 2008 3:41 PM, Oriol <oripipa(a)yahoo.es> wrote:
>> I get an error while trying to install Firefox 2.0 on a bootcd
>> compilation, finally i found the possibly bug is in vfatfs.sys i
>> modified some lines but is not my code.....it seems to install
>> Firefox.
>> Also, testing firefox i found problems with gdi and also done some
>> modifications, still testing them..
>> Here is my patch..NO WARRANTY he he..
Hi Oriol,
now you can send the vfatfs.sys patch ;)
Kind regards,
Sylvain Petreolle (aka Usurp)
Je ne suis pas d'accord avec ce que vous dites, mais je me battrai jusqu'à la mort pour que vous ayez le droit de le dire.I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - VoltaireRun your favorite Windows apps with free ReactOS : http://www.reactos.orgListen to non-DRMised Music: http://www.jamendo.com
----- Message d'origine ----
De : Oriol <oripipa(a)yahoo.es>
À : ros-dev(a)reactos.org
Envoyé le : Jeudi, 3 Janvier 2008, 22h41mn 57s
Objet : [ros-dev] bug in vfatfs.sys?
I get an error while trying to install Firefox 2.0 on a bootcd
compilation, finally i found the possibly bug is in vfatfs.sys i
modified some lines but is not my code.....it seems to install Firefox.
Also, testing firefox i found problems with gdi and also done some
modifications, still testing them..
Here is my patch..NO WARRANTY he he..
Can you fill the headers out correctly please?
See any other the other reactos sources as to how this is done.
There's also a wiki page detailing this.
Thanks,
Ged.
+/*
+ * ReactOS kernel
+ * Copyright (C) 2003 ReactOS Team
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+/* $Id: registry.h 21704 2006-04-22 13:55:01Z tretiakov $
+ * COPYRIGHT: See COPYING in the top level directory
+ * PROJECT: ReactOS text-mode setup
+ * FILE: subsys/system/usetup/errcode.h
+ * PURPOSE:
+ * PROGRAMMER:
+ */