Sorry for IRC channel flood because of the huge commit log of r62283. As
someone just suggested, I could have used indeed a Jira task for that
/me apologises.
Hermès.
Well, it would make sense to talk to Christoph first. It's not THAT
obvious where the real bug is, and he might have been willing to try to
find it and fix.
Regards,
Aleksey Bragin
On 21.02.2014 0:17, hbelusca(a)svn.reactos.org wrote:
> Author: hbelusca
> Date: Thu Feb 20 20:17:53 2014
> New Revision: 62267
>
> URL: http://svn.reactos.org/svn/reactos?rev=62267&view=rev
> Log:
> [KERNEL32]
> Revert r62264.
> Reason: all APIs set the last error when a CSR* call doesn't return STATUS_SUCCESS. If some winetests fail because of this, this is because we do not correctly do what's needed here (normally the TRUE or FALSE value is returned by the console server, and is not retrieved by a success or failure of a CSR call contrary to what's done here).
>
> Modified:
> trunk/reactos/dll/win32/kernel32/client/console/console.c
>
> Modified: trunk/reactos/dll/win32/kernel32/client/console/console.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/…
> ==============================================================================
> --- trunk/reactos/dll/win32/kernel32/client/console/console.c [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/kernel32/client/console/console.c [iso-8859-1] Thu Feb 20 20:17:53 2014
> @@ -796,6 +796,7 @@
> sizeof(CONSOLE_VERIFYHANDLE));
> if (!NT_SUCCESS(Status))
> {
> + BaseSetLastNTError(Status);
> return FALSE;
> }
>
>
>
Hi David
> + if (m_staticToolbar != NULL)
> + hr = m_staticToolbar->GetWindow(&hwndStatic);
> + if (FAILED(hr))
> + return hr;
You are using potentially uninitialized variable here. are you compiling
without "-Werror" (or /WX on msvc)?
Keep it up :-)
Greetings
Jérôme
SP2 was not out when we made the choice.
And before we move to SP2, I'd rather move to Win 7 =)
--
Best regards,
Alex Ionescu
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of hbelusca(a)svn.reactos.org
Sent: Wednesday, February 12, 2014 2:58 PM
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [hbelusca] 62142: [REACTOS] Revert r62140 per Alex request. Alex, why did we choose Win2k3 SP1 at first, and not SP2 directly? CORE-6611 #comment Reverted in r62142.
Author: hbelusca
Date: Wed Feb 12 22:58:13 2014
New Revision: 62142
URL: http://svn.reactos.org/svn/reactos?rev=62142&view=rev
Log:
[REACTOS]
Revert r62140 per Alex request.
Alex, why did we choose Win2k3 SP1 at first, and not SP2 directly?
CORE-6611 #comment Reverted in r62142.
Modified:
trunk/reactos/boot/bootdata/hivesys.inf
trunk/reactos/include/psdk/ntverp.h
trunk/reactos/ntoskrnl/ex/init.c
Modified: trunk/reactos/boot/bootdata/hivesys.inf
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys.inf?…
==============================================================================
--- trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] (original)
+++ trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] Wed Feb 12 22:58:13 2014
@@ -1143,8 +1143,8 @@
; ReactOS specific - by default we report ourselves as Server for the user, ; but we can also report as Workstation if some application needs it.
HKLM,"SYSTEM\CurrentControlSet\Control\ReactOS\Settings\Version","ReportAsWorkstation",0x00010001,0x00000000
-; Some installers check for SP2
-HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001,0x00000200
+; Some installers check for SP1
+HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001
+,0x00000100
HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders","SecurityProviders",2,"schannel.dll"
HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders\SaslProfiles",,0x00000012
Modified: trunk/reactos/include/psdk/ntverp.h
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ntverp.h?rev=…
==============================================================================
--- trunk/reactos/include/psdk/ntverp.h [iso-8859-1] (original)
+++ trunk/reactos/include/psdk/ntverp.h [iso-8859-1] Wed Feb 12 22:58:13 2014
@@ -14,10 +14,10 @@
*/
//
-// Windows NT Build 3790.3959
+// Windows NT Build 3790.1830
//
#define VER_PRODUCTBUILD 3790
-#define VER_PRODUCTBUILD_QFE 3959
+#define VER_PRODUCTBUILD_QFE 1830
//
// Windows NT Version 5.2
Modified: trunk/reactos/ntoskrnl/ex/init.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=621…
==============================================================================
--- trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] Wed Feb 12 22:58:13 2014
@@ -1072,12 +1072,12 @@
/* Setup initial system settings */
CmGetSystemControlValues(LoaderBlock->RegistryBase, CmControlVector);
- /* Load static defaults for Service Pack 2 and add our SVN revision */
+ /* Load static defaults for Service Pack 1 and add our SVN revision
+ */
/* Format of CSD : SPMajor - SPMinor */
- CmNtCSDVersion = 0x200 | (KERNEL_VERSION_BUILD_HEX << 16);
+ CmNtCSDVersion = 0x100 | (KERNEL_VERSION_BUILD_HEX << 16);
CmNtCSDReleaseType = 0;
- /* Set Service Pack data for Service Pack 2 */
+ /* Set Service Pack data for Service Pack 1 */
CmNtSpBuildNumber = VER_PRODUCTBUILD_QFE;
if (!(CmNtCSDVersion & 0xFFFF0000))
{
I am so sick of these types of changes being made without consultation.
The kernel is not SP2. Please do not update this value, as we are
missing exports/functionality exposed on SP2.
Best regards,
Alex Ionescu
On Wed, Feb 12, 2014 at 12:03 PM, <hbelusca(a)svn.reactos.org> wrote:
> Author: hbelusca
> Date: Wed Feb 12 20:03:57 2014
> New Revision: 62140
>
> URL: http://svn.reactos.org/svn/reactos?rev=62140&view=rev
> Log:
> [REACTOS]
> Go fully to Win2k3 SP2 version reporting.
> CORE-6611 #resolve #comment Fixed in r62140.
>
> Modified:
> trunk/reactos/boot/bootdata/hivesys.inf
> trunk/reactos/include/psdk/ntverp.h
> trunk/reactos/ntoskrnl/ex/init.c
>
> Modified: trunk/reactos/boot/bootdata/hivesys.inf
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys.inf?…
> ==============================================================================
> --- trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] (original)
> +++ trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] Wed Feb 12 20:03:57 2014
> @@ -1143,8 +1143,8 @@
> ; ReactOS specific - by default we report ourselves as Server for the user,
> ; but we can also report as Workstation if some application needs it.
> HKLM,"SYSTEM\CurrentControlSet\Control\ReactOS\Settings\Version","ReportAsWorkstation",0x00010001,0x00000000
> -; Some installers check for SP1
> -HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001,0x00000100
> +; Some installers check for SP2
> +HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001,0x00000200
>
> HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders","SecurityProviders",2,"schannel.dll"
> HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders\SaslProfiles",,0x00000012
>
> Modified: trunk/reactos/include/psdk/ntverp.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ntverp.h?rev=…
> ==============================================================================
> --- trunk/reactos/include/psdk/ntverp.h [iso-8859-1] (original)
> +++ trunk/reactos/include/psdk/ntverp.h [iso-8859-1] Wed Feb 12 20:03:57 2014
> @@ -14,10 +14,10 @@
> */
>
> //
> -// Windows NT Build 3790.1830
> +// Windows NT Build 3790.3959
> //
> #define VER_PRODUCTBUILD 3790
> -#define VER_PRODUCTBUILD_QFE 1830
> +#define VER_PRODUCTBUILD_QFE 3959
>
> //
> // Windows NT Version 5.2
>
> Modified: trunk/reactos/ntoskrnl/ex/init.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=621…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] Wed Feb 12 20:03:57 2014
> @@ -1072,12 +1072,12 @@
> /* Setup initial system settings */
> CmGetSystemControlValues(LoaderBlock->RegistryBase, CmControlVector);
>
> - /* Load static defaults for Service Pack 1 and add our SVN revision */
> + /* Load static defaults for Service Pack 2 and add our SVN revision */
> /* Format of CSD : SPMajor - SPMinor */
> - CmNtCSDVersion = 0x100 | (KERNEL_VERSION_BUILD_HEX << 16);
> + CmNtCSDVersion = 0x200 | (KERNEL_VERSION_BUILD_HEX << 16);
> CmNtCSDReleaseType = 0;
>
> - /* Set Service Pack data for Service Pack 1 */
> + /* Set Service Pack data for Service Pack 2 */
> CmNtSpBuildNumber = VER_PRODUCTBUILD_QFE;
> if (!(CmNtCSDVersion & 0xFFFF0000))
> {
>
>
Hi all,
Pierre and me changed the HTTP server software on the VM for
build.reactos.org, git.reactos.org, source.reactos.org and
svn.reactos.org today.
This may or may not fix the performance issues people were recently
experiencing at git.reactos.org. At least, the stability has improved
and the full configuration is less complex, making further changes easier.
If anything got noticably worse, please report here.
Cheers,
Colin
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 30th of January, 19:00 UTC. Put that into your
calendars so you don't forget. And that's in two days!
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts). Hermes sent
the first suggestion well before the meeting, so please follow his
example and send your suggestions too.
Regards,
Aleksey Bragin
What about reading the current TickCount from the shared user page?
Am 29.01.2014 01:25, schrieb hbelusca(a)svn.reactos.org:
> Author: hbelusca
> Date: Wed Jan 29 00:25:43 2014
> New Revision: 61875
>
> URL: http://svn.reactos.org/svn/reactos?rev=61875&view=rev
> Log:
> [NTVDM]
> - Enable experimental sound support (only PC speaker for the moment, aka. uses beep.sys).
> - Introduce a #define WORKING_TIMER which aim is to disable the currently problematic approximate performance counter value calculation done in order not to call QueryPerformanceCounter each time.
> The problem is that we then compute a number of clock ticks for the PIT, which becomes negative, and therefore everything starts to hang.
> Disabling this code and calling each time QueryPerformanceCounter, fixes everything; we gain in precision but we loose in performance...
> A definitive fix must be found, [TheFlash] !!
>
> This fixes sound (and hangs) in Advanced NetWars, Dangerous Dave, ElitePlus and Rescue Rover (the games that I've tested so far).
>
>
Hello!
This is my fix to an error in pefixup tool.
The section count was taken from a wrong struct member and the tool
only worked (when worked) by chance.
Hello all,
XP support will come to end on April this year, and i suppose GPU vendors
and manufacturers will drop driver releases for those systems as well.
So, my question is, what about trying to contact them and try to convince
them to release those drivers as "ReactOS" instead of "Windows XP"? :)
Hi!
You may have noticed that my latest patch causes buildbot failures. This
happens because the patch breaks winlogons AutoAdminLogon feature.
Please do not revert that patch! I'll provide a fix for the
AutoAdminLogon feature as soon as possible.
Regards
Eric
On 2014.01.03 18:58, Thomas Mueller wrote:
> What I would like to do, and about the only way I can see and test
> ReactOS, is to build from RosBE from FreeBSD or Linux, or Wine, and
> install onto a USB stick without having to make an intermediate
> boot/installation medium.
Then today may be your lucky day... ;)
But first things first (you may skip this part if you're only interested
in UNIX, as Rufus is Windows only): Besides ISO support through
Syslinux, the new BETA of Rufus [1] also adds the ability to install the
ReactOS boot records, so that one can then boot freeldr.sys directly
from USB. Unlike what's the case for the ISO, this is a bare install, so
you will still need to copy your own freeldr.sys, freeldr.ini and
relevant files to the USB. However, the hard part of the install
(modifying the boot records) should now be taken care of for you.
Now, since this is an advanced feature, it's not made available in the
UI by default. To access the bare ReactOS boot record installation, you
must first enable Advanced Mode in Rufus, by clicking the white triangle
next to "Format Options" and only then will you see "ReactOS" listed in
the "Create a bootable disk" dropdown. It's the same way Rufus provides
bare installation of Syslinux v4 & v5 boot records.
I tested freeldr.sys boot from USB using this method, after copying the
same set of files as the one ReactOS creates for second stage
installation, and it seems to work as good as one might expect (boots
brilliantly, but then runs into ReactOS 0x7b, due to issues with USB
support - at least on the systems I'm testing with).
I may eventually use this method to support ISOs, but for now, I'll
stick with the syslinux -> mboot.c32 -> setupldr.sys for ISO support,
while the direct freeldr.sys for more adventurous people.
Now, what may be of more interest for UNIX-derivative users, is that
what Rufus really uses behind the scenes to install boot blocks is its
own integrated version of ms-sys [2]. Thus, since I added ReactOS
support in my own embedded version of ms-sys, I also went ahead and
produced a generic UNIX version that can install the ReactOS bootblocks
from the commandline, for freeldr support.
To use it, you'll first need to clone the relevant github repository [3]
and then switch to the "rufus" branch of that repo, which is where I
added the changes.
I'm also providing a fully detailed example of a run (git clone, branch
switch, installation, etc), in the attached log, but basically, what you
want to run is:
1. Fetching & compiling the source
# git clone https://github.com/pbatard/ms-sys.git
# cd ms-sys/
# git checkout rufus
# make
2. Installing the ReactOS boot blocks on an USB drive, here /dev/sda,
after blanking its first sectors:
# dd if=/dev/zero of=/dev/sda bs=8M count=8
# fdisk /dev/sda => create a FAT32 bootable partition
# mkdosfs -F 32 /dev/sda1
# ./bin/ms-sys -0 /dev/sda => install the ReactOS MBR
# ./bin/ms-sys -O /dev/sda1 => install the ReactOS FAT32 PBR
# ./bin/ms-sys -p /dev/sda1 => write partition info [REQUIRED!]
Then you can just copy your files, and boot the drive.
Note that the MBR option is -0 (minus zero) and the second -O (minus
uppercase O), and also that your drive _will NOT boot_ unless you also
apply the -p option. Oh and if you want to complain about ms-sys (yeah,
it would probably be nicer if it used getopt so that you could run
multiple options at once), please remember that:
1. I am not the author of ms-sys
2. I use my own non-commandline, non-UNIX compatible version in Rufus
This means that, due to time constraints, I have little interest in
improving my UNIX/ReactOS version of ms-sys (to add ext2 support for
instance). I created it as fast as I could, in the hope that it would be
useful for UNIX people (only tested FAT32 - I kind of expect FAT16 to be
broken), and I may see with the author (Henrik Carlqvist) if he wants to
integrate the ReactOS patches, but that'll be about it.
> There ought to be something like "make install DESTDIR=...".
Hopefully, now that you can use ms-sys on Linux/FreeBSD, you should be
able to add an install step, that can invoke ms-sys to create a whole
Live/USB system from scratch, to install the newly generated development
binaries.
"All" that remains then, is to fix USB support in ReactOS, so that such
a system can run as expected... ;)
Regards,
/Pete
[1] http://rufus.akeo.ie/downloads/
[2] http://ms-sys.sourceforge.net/
[3] https://github.com/pbatard/ms-sys/tree/rufus
root@sheeva:/usr/src# git clone https://github.com/pbatard/ms-sys.git
Cloning into ms-sys...
remote: Counting objects: 306, done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 306 (delta 203), reused 302 (delta 199)
Receiving objects: 100% (306/306), 84.59 KiB, done.
Resolving deltas: 100% (203/203), done.
root@sheeva:/usr/src# cd ms-sys/
root@sheeva:/usr/src/ms-sys# git checkout rufus
Branch rufus set up to track remote branch rufus from origin.
Switched to a new branch 'rufus'
root@sheeva:/usr/src/ms-sys# make
mkdir -p dep
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/partition_info.d src/partition_info.c > dep/partition_info.d
mkdir -p obj
mkdir -p bin
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/partition_info.o src/partition_info.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/ntfs.d src/ntfs.c > dep/ntfs.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/ntfs.o src/ntfs.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat12.d src/fat12.c > dep/fat12.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat12.o src/fat12.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat16.d src/fat16.c > dep/fat16.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat16.o src/fat16.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/file.d src/file.c > dep/file.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/file.o src/file.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/br.d src/br.c > dep/br.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/br.o src/br.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/nls.d src/nls.c > dep/nls.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/nls.o src/nls.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/main.d src/main.c > dep/main.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/main.o src/main.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat32.d src/fat32.c > dep/fat32.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat32.o src/fat32.c
cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/identify.d src/identify.c > dep/identify.d
cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/identify.o src/identify.c
cc -o bin/ms-sys obj/partition_info.o obj/ntfs.o obj/fat12.o obj/fat16.o obj/file.o obj/br.o obj/nls.o obj/main.o obj/fat32.o obj/identify.o
mkdir -p mo
msgfmt -o mo/sv.mo po/sv.po
root@sheeva:/usr/src/ms-sys# dd if=/dev/zero of=/dev/sda bs=8M count=8
8+0 records in
8+0 records out
67108864 bytes (67 MB) copied, 2.41523 s, 27.8 MB/s
root@sheeva:/usr/src/ms-sys# fdisk /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x7759d579.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4, default 1): 1
First sector (2048-63487999, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-63487999, default 63487999):
Using default value 63487999
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): a
Partition number (1-4): 1
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
root@sheeva:/usr/src/ms-sys# mkdosfs -F 32 /dev/sda1
mkdosfs 2.11 (12 Mar 2005)
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -0 /dev/sda
ReactOS master boot record successfully written to /dev/sda
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys /dev/sda
/dev/sda has an x86 boot sector,
it is a ReactOS master boot record, like the one this
program creates with the switch -r on a hard disk device.
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -O /dev/sda1
FAT32 ReactOS boot record successfully written to /dev/sda1
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -p /dev/sda1
Start sector 2048 (nr of hidden sectors) successfully written to /dev/sda1
Physical disk drive id 0x80 (C:) successfully written to /dev/sda1
Number of heads (64) successfully written to /dev/sda1
root@sheeva:/usr/src/ms-sys# ./bin/ms-sys /dev/sda1
/dev/sda1 has a FAT32 file system.
/dev/sda1 has an x86 boot sector,
it is exactly the kind of FAT32 ReactOS boot record this program
would create with the switch -O on a FAT32 partition.
root@sheeva:/usr/src/ms-sys# mount /dev/sda1 /mnt/usb/
root@sheeva:/usr/src/ms-sys# ls /ext/reactos_files/
ReactOS/ freeldr.ini freeldr.sys
root@sheeva:/usr/src/ms-sys# ls /mnt/usb
root@sheeva:/usr/src/ms-sys# cp -r /ext/reactos_files/* /mnt/usb
root@sheeva:/usr/src/ms-sys# ls /mnt/usb
ReactOS/ freeldr.ini* freeldr.sys*
root@sheeva:/usr/src/ms-sys# umount /mnt/usb
root@sheeva:/usr/src/ms-sys#
Pete Batard schreef op 3-1-2014 3:59:
> If you want to test, you can pick the latest ALPHA from:
> http://rufus.akeo.ie/downloads/
Awesome, will test using USB2 ports.
> Currently, the way this works is through installing Syslinux (v4.07) and
> mboot.c32 so that setupldr.sys can then be invoked (see the
> /syslinux.cfg created by Rufus on the drive).
>
> Also, for the time being, only setupldr.sys will be referenced (no
> freeldr.sys) on account that:
FreeLDR as multiboot-kernel only looks at freeldr.ini at C:\ , no idea
if your created USB stick counts as C: or A:.
Also ReactOS might write freeldr.ini in some special way on FAT drives,
I've never been able to open/modify it using a DOS text editor.
> 1. The Syslinux's menu.c32 file is rather large, and I want to keep
> Rufus small, so I don't want to embed it in the application (which is
> also the mais reason why Rufus doesn't include native GRUB support). But
> this means that user selection from a menu is not available.
>
> 2. When testing, I couldn't get freeldr.sys to do much when booted from
> USB... though that was most likely because I hadn't actually installed
> ReactOS anywhere.
Smallest I've gotten FreeLDR is through using
SYSLINUX -> MEMDISK -> FLOPPY.GZ where floppy.gz is a compressed ReactOS
startup diskette image. SYSLINUX -> MBOOT.C32 -> FREELDR.GZ might also
work instead.
> Still, I'm hoping that making the creation of a bootable UFD easier for
> ReactOS will help encourage more people to test it and help the project.
I've always hoped for Syslinux -> Memdisk/GRUB -> ReactOS.ISO/IMG simply
to overcome lack of mass storage controllers drivers by running from RAM.
> Of course, I'm also open to suggestions to try to improve support for
> ReactOS in Rufus, if you want something specific. For instance, I should
> point out that the syslinux.cfg created by Rufus is written before any
> of the ISO files are copied over. Thus, if the ReactOS ISOs were to
> include their own syslinux.cfg & menu.c32/vesamenu.c32, it would be very
> easy to provide menu selection for the user when booting from USB, even
> as the ISOs are not Syslinux/Isolinux based.
So right now the installer ISO works but not the LiveCD/USB?
[ https://www.reactos.org/getbuilds ] with rev 61493
Thanks for having implemented the support Pete! :)
Have fun with HaikuOS :)
best wishes for 2014,
Bernd
Hi!
since 2013 is almost over, it is time to make some plans for 2014.
My primary goals for 2014 are:
- Completing the user account management, user logon and password change.
- Fixing winlogon.exe in order to enable users to lock and unlock the
computer and to change their identity (log-off and log-on again).
- Fix potential bugs in userenv.dll. We need to get rid of the
administrator logon hack in syssetup.dll.
- Fix the system shutdown: We need to terminate applications and
services before the machine shuts down.
Secondary goals are:
- Implement PNP support for scsiport.sys.
- Improvements to PNP and driver installation.
- Get some legacy hardware working (parallel port, PCMCIA).
The items of this list and their priorities are not fixed. I reserverve
the right to make changes to this list or to work on something entirely
different, without prior notice.
Happy new year!
Regards
Eric
Hi,
this message is a bit provocative, but please don't be offended by it.
You all did a wonderful work during this year. Thank you!
It's very good to see the work is going on. Just for fun, when I had
spare 15 minutes, I decided to check, what was done in the win32
subsystem during this year by the major, respectable and very old time
ReactOS developer, and whether my proposal with Arwinss still stands or not.
Here is what I found: (analyzing ~ 62 commits by jimtabor):
- 25 revisions: Fixes/hacks of our code (ReactOS-specific bug, works in
Wine, sometimes says in comments "//// ReactOS : Justin Case something
goes wrong.") (revs 58528, 58562, 58563, 58633, 58773, 58999, 59000,
59201, 60054, 60587, 60590, 60592, 60622, 60626, 60659, 60676, 60677,
60881, 61078, 61079, 61142, 61250, 61251, 61292, 61458)
- 13 revisions: Syncs with Wine (revs 59157, 59158, 59159, 60763, 60784,
60807, 60820, 60858, 60863, 60865, 60867, 61244, 61422)
- 14 revisions: Own code development or rewriting old code, some of
which might have been derived from ancient versions of Wine.
(60387, 60389, 60394, 60539, 60599, 60602, 60660, 60682, 60683, 60684,
60718, 60883, 60976, 60992)
- 1 revision: attempt to fix a bug found in Wine (revision 60054, issue
CORE-6024)
You don't need to be a scientist to see that 61% of the changes went
into fixing ReactOS specific bugs or just bringing in newer Wine code to
fix old Wine bugs. Remaining 22% of efforts was spent on actually
developing our own, assumingly better code, and just 1 revision was
spent on such a glorious thing as fixing Wine's bug.
ReactOS is a just for fun type of project, so I highly appreciate that
efforts were put into all of the above!
However, I still think that it would be beneficial if someone would put
similar efforts into Arwinss to eliminate the need to bring in hacks and
fix stuff which works in Wine for years already, and focus on developing
only those parts which we obviously can't share (GDI, hardware
accelerated graphics, whatever else).
I lack time to do this myself, but if anyone volunteers I would be glad
to help, share my experience and think up of interesting tasks. Like,
getting Arwinss to work in Windows 2003 instead of its native subsystem,
which would be a nice test.
Regards,
Aleksey Bragin
On 2013-12-25 23:47, pschweitzer(a)svn.reactos.org wrote:
> +TryWithVolumeName:
> + /* If we didn't find anything, try differently */
> + if (DeviceLength < 2 * sizeof(WCHAR) || DeviceString[2] != L':')
This looks like a buffer overrun. Did you mean < 3 * sizeof(WCHAR)?
A pity.
-------- Original Message --------
Subject: Your stand proposal for ReactOS has been rejected
Date: Mon, 16 Dec 2013 22:28:19 +0100 (CET)
From: FOSDEM Stands Team <stands(a)fosdem.org>
To: Aleksey Bragin <aleksey(a)reactos.org>
Hi Aleksey,
The FOSDEM stands team is sorry to have to inform you that your request
for a stand for ReactOS has been rejected.
We have received almost twice as many proposals as we could accept,
and we regret not being able to give everyone a stand.
We hope to see you at FOSDEM 2014 in a different capacity regardless.
Kind regards,
Wynke Stulemeijer
FOSDEM stands team
This is a suboptimal way of handling it, because it will cause the
compiler to instantiate all GUIDs in all compilation units. When linking
only one will be selected for the executable, but still it increases the
size of all object files. If it is to allow a precompiled header, I
suggest adding an additional guid.c file, that only includes the guid
headers, not the precompiled header.
Timo
Am 24.12.2013 21:58, schrieb akhaldi(a)svn.reactos.org:
> Author: akhaldi
> Date: Tue Dec 24 20:58:27 2013
> New Revision: 61381
>
> URL: http://svn.reactos.org/svn/reactos?rev=61381&view=rev
> Log:
> [USBSTOR]
> * Define INITGUID in the main header.
> CORE-7716
>
> Modified:
> trunk/reactos/drivers/usb/usbstor/usbstor.c
> trunk/reactos/drivers/usb/usbstor/usbstor.h
>
> Modified: trunk/reactos/drivers/usb/usbstor/usbstor.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/usbstor/usbsto…
> ==============================================================================
> --- trunk/reactos/drivers/usb/usbstor/usbstor.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/usb/usbstor/usbstor.c [iso-8859-1] Tue Dec 24 20:58:27 2013
> @@ -10,7 +10,6 @@
>
> /* INCLUDES ******************************************************************/
>
> -#define INITGUID
> #include "usbstor.h"
>
> #define NDEBUG
>
> Modified: trunk/reactos/drivers/usb/usbstor/usbstor.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/usbstor/usbsto…
> ==============================================================================
> --- trunk/reactos/drivers/usb/usbstor/usbstor.h [iso-8859-1] (original)
> +++ trunk/reactos/drivers/usb/usbstor/usbstor.h [iso-8859-1] Tue Dec 24 20:58:27 2013
> @@ -1,5 +1,7 @@
>
> #pragma once
> +
> +#define INITGUID
>
> #include <ntddk.h>
> #include <usbdi.h>
>
>
>
Hi Eric,
I know this has been discussed before, but should we not just bite the bullet and replace this driver with the Microsoft driver.
The MS_LPL license allows it to be used in reactos, and it would certainly get rid of any unknowns and give us a reliable filesystem to work from.
http://code.msdn.microsoft.com/windowshardware/fastfat-File-System-Driver-1…
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of ekohl(a)svn.reactos.org
Sent: 29 November 2013 14:06
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.
Author: ekohl
Date: Fri Nov 29 14:05:43 2013
New Revision: 61145
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 28th of November, 19:00 UTC. Put that into your
calendars so you don't forget. And that's tomorrow!
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts). Hermes sent
the first suggestion well before the meeting, so please follow his
example and send your suggestions too.
Regards,
Aleksey Bragin
I heard that ReactOS is nearly 80 or not yet 80 percent complete.
I feel that if we are seriously going to for true compatibility with
Microsoft Windows it may be a necessary evil to contact Microsoft about this
MS-LPL license--and other things.
It may be that don't really care either way. It may be they do. But its
better to know then not to know in this case I feel. I know the feelings
about proprietary code and avoid trade secrets. But what if a good
relationship with Microsoft makes or breaks ReactOS?
I mean the worst thing that Microsoft will do is say no, or give bogus terms
of use. But your expecting that.
What if they start to contribute to ReactOS because they see you have a good
product, and you are reputable people.
-------Original Message-------
From: ros-dev-request(a)reactos.org
Date: 11/29/13 14:32:25
To: ros-dev(a)reactos.org
Subject: Ros-dev Digest, Vol 111, Issue 24
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] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
(Alexander Andrejevic)
2. Re: [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
(Pierre Schweitzer)
3. Re: [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
(Herm?s B?LUSCA - MA?TO)
4. Re: [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
(Aleksey Bragin)
----------------------------------------------------------------------
Message: 1
Date: Fri, 29 Nov 2013 17:05:12 +0000
From: Alexander Andrejevic <theflash(a)sdf.lonestar.org>
To: ReactOS Development List <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
Message-ID: <20131129170512.GB11454(a)SDF.ORG>
Content-Type: text/plain; charset=us-ascii
I suppose it depends on how you interpret it.
To me, "...extend only to the software or derivative works that you create
that run
on a Microsoft Windows operating system product" sounds like the program
must run
on Windows exclusively. It's not "... that you create to run ...", but "...
that you
create that run ...".
Regards,
Alexander
On Fri, Nov 29, 2013 at 05:55:08PM +0100, David Quintana (gigaherz) wrote:
> I do not agree on the "unless it's on Microsoft Windows" part. The
> license grants apply if it is "created to run directly" on windows,
> which I understand as "it can run anywhere else, also, just as long as
> it runs in windows without an intermediary".
>
> On 29 November 2013 17:51, Alexander Andrejevic
> <theflash(a)sdf.lonestar.org> wrote:
> > Fastfat is located inside its own binary, so this is considered "mere
aggregation", and
> > that is not the problem. (See https://www.gnu.org/licenses/gpl-faq
html#MereAggregation).
> > The problem is that you don't even have a license to use it or
distribute it, unless it's
> > on Microsoft Windows.
> > Then again, I'm not a lawyer either and I could be wrong too. It would
be great if someone
> > who knows a lot about licenses explained this.
> >
> > Regards,
> > Alexander
> >
> > On Fri, Nov 29, 2013 at 05:35:21PM +0100, David Quintana (gigaherz)
wrote:
> >> The exact words of the license, as seen at
> >> http://www.ohloh.net/licenses/mslpl (I couldn't find a better link for
> >> it), are:
> >>
> >> "4. (F) Platform Limitation- The licenses granted in sections 2(A) &
> >> 2(B) extend only to the software or derivative works that you create
> >> that run on a Microsoft Windows operating system product."
> >>
> >> Excluding that term, the rest of the license is mostly a
> >> differently-worded BSD license. If it only needs to be tested in
> >> windows to ensure that it works there, then there should be absolutely
> >> no problem including it in ReactOS, as long as the terms don't
> >> conflict with the other licenses' terms. And GPL with the ReactOS
> >> exception, as far as I can tell, allows it. I'm not a lawyer, though,
> >> so I could be wrong.
> >>
> >> On 29 November 2013 16:17, Alexander Andrejevic
> >> <theflash(a)sdf.lonestar.org> wrote:
> >> > Hi Ged,
> >> >
> >> > Are you sure that we can use software released under the MS-LPL? It
has a rather weird
> >> > limitation in section 4, which says that you can only use it on a
Microsoft Windows operating system product".
> >> > Since ReactOS is not Windows, that would mean we can't use it.
> >> > Please correct me if I'm wrong.
> >> >
> >> > Regards,
> >> > Alexander
> >> >
> >> > On Fri, Nov 29, 2013 at 02:58:51PM -0000, Ged Murphy wrote:
> >> >> Hi Eric,
> >> >>
> >> >> I know this has been discussed before, but should we not just bite
the bullet and replace this driver with the Microsoft driver.
> >> >> The MS_LPL license allows it to be used in reactos, and it would
certainly get rid of any unknowns and give us a reliable filesystem to work
from.
> >> >>
> >> >> http://code.msdn.microsoft
com/windowshardware/fastfat-File-System-Driver-135bdf34/view/SourceCode
> >> >>
> >> >> Ged.
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: ros-diffs-bounces(a)reactos.org
[mailto:ros-diffs-bounces@reactos.org] On Behalf Of ekohl(a)svn.reactos.org
> >> >> Sent: 29 November 2013 14:06
> >> >> To: ros-diffs(a)reactos.org
> >> >> Subject: [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
> >> >>
> >> >> Author: ekohl
> >> >> Date: Fri Nov 29 14:05:43 2013
> >> >> New Revision: 61145
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Ros-dev mailing list
> >> >> Ros-dev(a)reactos.org
> >> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >> >
> >> > --
> >> > Alexander Andrejevic <theflash(a)sdf.lonestar.org>
> >> > SDF Public Access UNIX System - http://sdf.lonestar.org
> >> >
> >> > _______________________________________________
> >> > 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
> >
> > --
> > Alexander Andrejevic <theflash(a)sdf.lonestar.org>
> > SDF Public Access UNIX System - http://sdf.lonestar.org
> >
> > _______________________________________________
> > 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
--
Alexander Andrejevic <theflash(a)sdf.lonestar.org>
SDF Public Access UNIX System - http://sdf.lonestar.org
------------------------------
Message: 2
Date: Fri, 29 Nov 2013 18:24:23 +0100
From: Pierre Schweitzer <pierre(a)reactos.org>
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
Message-ID: <5298CDC7.7030300(a)reactos.org>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
Let's the experts do.
I've contacted the April (French association which mission is to promote
and defend FOSS). They can answer about licensing issues (they propose
it through their contact form).
I'll keep you informed with their answers, highlights, and so on.
Regards,
On 11/29/2013 06:05 PM, Alexander Andrejevic wrote:
> I suppose it depends on how you interpret it.
> To me, "...extend only to the software or derivative works that you create
that run
> on a Microsoft Windows operating system product" sounds like the program
must run
> on Windows exclusively. It's not "... that you create to run ...", but "..
that you
> create that run ...".
>
> Regards,
> Alexander
>
> On Fri, Nov 29, 2013 at 05:55:08PM +0100, David Quintana (gigaherz) wrote:
>> I do not agree on the "unless it's on Microsoft Windows" part. The
>> license grants apply if it is "created to run directly" on windows,
>> which I understand as "it can run anywhere else, also, just as long as
>> it runs in windows without an intermediary".
>>
>> On 29 November 2013 17:51, Alexander Andrejevic
>> <theflash(a)sdf.lonestar.org> wrote:
>>> Fastfat is located inside its own binary, so this is considered "mere
aggregation", and
>>> that is not the problem. (See https://www.gnu.org/licenses/gpl-faq
html#MereAggregation).
>>> The problem is that you don't even have a license to use it or
distribute it, unless it's
>>> on Microsoft Windows.
>>> Then again, I'm not a lawyer either and I could be wrong too. It would
be great if someone
>>> who knows a lot about licenses explained this.
>>>
>>> Regards,
>>> Alexander
>>>
>>> On Fri, Nov 29, 2013 at 05:35:21PM +0100, David Quintana (gigaherz)
wrote:
>>>> The exact words of the license, as seen at
>>>> http://www.ohloh.net/licenses/mslpl (I couldn't find a better link for
>>>> it), are:
>>>>
>>>> "4. (F) Platform Limitation- The licenses granted in sections 2(A) &
>>>> 2(B) extend only to the software or derivative works that you create
>>>> that run on a Microsoft Windows operating system product."
>>>>
>>>> Excluding that term, the rest of the license is mostly a
>>>> differently-worded BSD license. If it only needs to be tested in
>>>> windows to ensure that it works there, then there should be absolutely
>>>> no problem including it in ReactOS, as long as the terms don't
>>>> conflict with the other licenses' terms. And GPL with the ReactOS
>>>> exception, as far as I can tell, allows it. I'm not a lawyer, though,
>>>> so I could be wrong.
>>>>
>>>> On 29 November 2013 16:17, Alexander Andrejevic
>>>> <theflash(a)sdf.lonestar.org> wrote:
>>>>> Hi Ged,
>>>>>
>>>>> Are you sure that we can use software released under the MS-LPL? It
has a rather weird
>>>>> limitation in section 4, which says that you can only use it on a
Microsoft Windows operating system product".
>>>>> Since ReactOS is not Windows, that would mean we can't use it.
>>>>> Please correct me if I'm wrong.
>>>>>
>>>>> Regards,
>>>>> Alexander
>>>>>
>>>>> On Fri, Nov 29, 2013 at 02:58:51PM -0000, Ged Murphy wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> I know this has been discussed before, but should we not just bite
the bullet and replace this driver with the Microsoft driver.
>>>>>> The MS_LPL license allows it to be used in reactos, and it would
certainly get rid of any unknowns and give us a reliable filesystem to work
from.
>>>>>>
>>>>>> http://code.msdn.microsoft
com/windowshardware/fastfat-File-System-Driver-135bdf34/view/SourceCode
>>>>>>
>>>>>> Ged.
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos
org] On Behalf Of ekohl(a)svn.reactos.org
>>>>>> Sent: 29 November 2013 14:06
>>>>>> To: ros-diffs(a)reactos.org
>>>>>> Subject: [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
>>>>>>
>>>>>> Author: ekohl
>>>>>> Date: Fri Nov 29 14:05:43 2013
>>>>>> New Revision: 61145
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ros-dev mailing list
>>>>>> Ros-dev(a)reactos.org
>>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>> --
>>>>> Alexander Andrejevic <theflash(a)sdf.lonestar.org>
>>>>> SDF Public Access UNIX System - http://sdf.lonestar.org
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> --
>>> Alexander Andrejevic <theflash(a)sdf.lonestar.org>
>>> SDF Public Access UNIX System - http://sdf.lonestar.org
>>>
>>> _______________________________________________
>>> 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
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4305 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.reactos
org/pipermail/ros-dev/attachments/20131129/a8e85e05/attachment-0001.bin>
------------------------------
Message: 3
Date: Fri, 29 Nov 2013 18:55:04 +0100
From: Herm?s B?LUSCA - MA?TO <hermes.belusca(a)sfr.fr>
To: 'ReactOS Development List' <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
Message-ID: <00db01ceed2c$223cffd0$66b6ff70$(a)sfr.fr>
Content-Type: text/plain; charset=iso-8859-1
Nice idea Pierre!
About this license we're talking about: yes I understand as Aleksander: that
you can only use fastfat or derived works from it, on an (authentic) Windows
OS (just my 2 cents, I'm not a lawyer too).
Herm?s.
-----Message d'origine-----
De?: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la
part de Pierre Schweitzer
Envoy??: vendredi 29 novembre 2013 18:24
??: ros-dev(a)reactos.org
Objet?: Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
Hi all,
Let's the experts do.
I've contacted the April (French association which mission is to promote and
defend FOSS). They can answer about licensing issues (they propose it
through their contact form).
I'll keep you informed with their answers, highlights, and so on.
Regards,
On 11/29/2013 06:05 PM, Alexander Andrejevic wrote:
> I suppose it depends on how you interpret it.
> To me, "...extend only to the software or derivative works that you
> create that run on a Microsoft Windows operating system product"
> sounds like the program must run on Windows exclusively. It's not "...
> that you create to run ...", but "... that you create that run ...".
>
> Regards,
> Alexander
>
> On Fri, Nov 29, 2013 at 05:55:08PM +0100, David Quintana (gigaherz) wrote:
>> I do not agree on the "unless it's on Microsoft Windows" part. The
>> license grants apply if it is "created to run directly" on windows,
>> which I understand as "it can run anywhere else, also, just as long
>> as it runs in windows without an intermediary".
>>
>> On 29 November 2013 17:51, Alexander Andrejevic
>> <theflash(a)sdf.lonestar.org> wrote:
>>> Fastfat is located inside its own binary, so this is considered
>>> "mere aggregation", and that is not the problem. (See
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation).
>>> The problem is that you don't even have a license to use it or
>>> distribute it, unless it's on Microsoft Windows.
>>> Then again, I'm not a lawyer either and I could be wrong too. It
>>> would be great if someone who knows a lot about licenses explained this.
>>>
>>> Regards,
>>> Alexander
>>>
>>> On Fri, Nov 29, 2013 at 05:35:21PM +0100, David Quintana (gigaherz)
wrote:
>>>> The exact words of the license, as seen at
>>>> http://www.ohloh.net/licenses/mslpl (I couldn't find a better link
>>>> for it), are:
>>>>
>>>> "4. (F) Platform Limitation- The licenses granted in sections 2(A)
>>>> &
>>>> 2(B) extend only to the software or derivative works that you
>>>> create that run on a Microsoft Windows operating system product."
>>>>
>>>> Excluding that term, the rest of the license is mostly a
>>>> differently-worded BSD license. If it only needs to be tested in
>>>> windows to ensure that it works there, then there should be
>>>> absolutely no problem including it in ReactOS, as long as the terms
>>>> don't conflict with the other licenses' terms. And GPL with the
>>>> ReactOS exception, as far as I can tell, allows it. I'm not a
>>>> lawyer, though, so I could be wrong.
>>>>
>>>> On 29 November 2013 16:17, Alexander Andrejevic
>>>> <theflash(a)sdf.lonestar.org> wrote:
>>>>> Hi Ged,
>>>>>
>>>>> Are you sure that we can use software released under the MS-LPL?
>>>>> It has a rather weird limitation in section 4, which says that you can
only use it on a "Microsoft Windows operating system product".
>>>>> Since ReactOS is not Windows, that would mean we can't use it.
>>>>> Please correct me if I'm wrong.
>>>>>
>>>>> Regards,
>>>>> Alexander
>>>>>
>>>>> On Fri, Nov 29, 2013 at 02:58:51PM -0000, Ged Murphy wrote:
>>>>>> Hi Eric,
>>>>>>
>>>>>> I know this has been discussed before, but should we not just bite
the bullet and replace this driver with the Microsoft driver.
>>>>>> The MS_LPL license allows it to be used in reactos, and it would
certainly get rid of any unknowns and give us a reliable filesystem to work
from.
>>>>>>
>>>>>> http://code.msdn.microsoft.com/windowshardware/fastfat-File-Syste
>>>>>> m-Driver-135bdf34/view/SourceCode
>>>>>>
>>>>>> Ged.
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ros-diffs-bounces(a)reactos.org
>>>>>> [mailto:ros-diffs-bounces@reactos.org] On Behalf Of
>>>>>> ekohl(a)svn.reactos.org
>>>>>> Sent: 29 November 2013 14:06
>>>>>> To: ros-diffs(a)reactos.org
>>>>>> Subject: [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
>>>>>>
>>>>>> Author: ekohl
>>>>>> Date: Fri Nov 29 14:05:43 2013
>>>>>> New Revision: 61145
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ros-dev mailing list
>>>>>> Ros-dev(a)reactos.org
>>>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>> --
>>>>> Alexander Andrejevic <theflash(a)sdf.lonestar.org> SDF Public Access
>>>>> UNIX System - http://sdf.lonestar.org
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> --
>>> Alexander Andrejevic <theflash(a)sdf.lonestar.org> SDF Public Access
>>> UNIX System - http://sdf.lonestar.org
>>>
>>> _______________________________________________
>>> 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
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
------------------------------
Message: 4
Date: Fri, 29 Nov 2013 23:31:03 +0400
From: Aleksey Bragin <aleksey(a)reactos.org>
To: ReactOS Development List <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT]
FsdGetFsVolumeInformation: Return volume creation time.
Message-ID: <5298EB77.7040509(a)reactos.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
To give you my position:
1. Current FAT driver in ReactOS needs to die away. I am testing all my
new code with the MS's FASTFAT driver.
2. Lawyers advice is needed whether we can distribute it.
Regards,
Aleksey Bragin
On 29.11.2013 21:55, Herm?s B?LUSCA - MA?TO wrote:
> Nice idea Pierre!
>
> About this license we're talking about: yes I understand as Aleksander:
that
> you can only use fastfat or derived works from it, on an (authentic)
Windows
> OS (just my 2 cents, I'm not a lawyer too).
>
> Herm?s.
>
> -----Message d'origine-----
> De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De
la
> part de Pierre Schweitzer
> Envoy? : vendredi 29 novembre 2013 18:24
> ? : ros-dev(a)reactos.org
> Objet : Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT]
> FsdGetFsVolumeInformation: Return volume creation time.
>
> Hi all,
>
> Let's the experts do.
>
> I've contacted the April (French association which mission is to promote
and
> defend FOSS). They can answer about licensing issues (they propose it
> through their contact form).
>
> I'll keep you informed with their answers, highlights, and so on.
>
> Regards,
>
> On 11/29/2013 06:05 PM, Alexander Andrejevic wrote:
>> I suppose it depends on how you interpret it.
>> To me, "...extend only to the software or derivative works that you
>> create that run on a Microsoft Windows operating system product"
>> sounds like the program must run on Windows exclusively. It's not "...
>> that you create to run ...", but "... that you create that run ...".
>>
>> Regards,
>> Alexander
>>
>> On Fri, Nov 29, 2013 at 05:55:08PM +0100, David Quintana (gigaherz)
wrote:
>>> I do not agree on the "unless it's on Microsoft Windows" part. The
>>> license grants apply if it is "created to run directly" on windows,
>>> which I understand as "it can run anywhere else, also, just as long
>>> as it runs in windows without an intermediary".
>>>
>>> On 29 November 2013 17:51, Alexander Andrejevic
>>> <theflash(a)sdf.lonestar.org> wrote:
>>>> Fastfat is located inside its own binary, so this is considered
>>>> "mere aggregation", and that is not the problem. (See
> https://www.gnu.org/licenses/gpl-faq.html#MereAggregation).
>>>> The problem is that you don't even have a license to use it or
>>>> distribute it, unless it's on Microsoft Windows.
>>>> Then again, I'm not a lawyer either and I could be wrong too. It
>>>> would be great if someone who knows a lot about licenses explained this
>>>>
>>>> Regards,
>>>> Alexander
>>>>
>>>> On Fri, Nov 29, 2013 at 05:35:21PM +0100, David Quintana (gigaherz)
> wrote:
>>>>> The exact words of the license, as seen at
>>>>> http://www.ohloh.net/licenses/mslpl (I couldn't find a better link
>>>>> for it), are:
>>>>>
>>>>> "4. (F) Platform Limitation- The licenses granted in sections 2(A)
>>>>> &
>>>>> 2(B) extend only to the software or derivative works that you
>>>>> create that run on a Microsoft Windows operating system product."
>>>>>
>>>>> Excluding that term, the rest of the license is mostly a
>>>>> differently-worded BSD license. If it only needs to be tested in
>>>>> windows to ensure that it works there, then there should be
>>>>> absolutely no problem including it in ReactOS, as long as the terms
>>>>> don't conflict with the other licenses' terms. And GPL with the
>>>>> ReactOS exception, as far as I can tell, allows it. I'm not a
>>>>> lawyer, though, so I could be wrong.
>>>>>
>>>>> On 29 November 2013 16:17, Alexander Andrejevic
>>>>> <theflash(a)sdf.lonestar.org> wrote:
>>>>>> Hi Ged,
>>>>>>
>>>>>> Are you sure that we can use software released under the MS-LPL?
>>>>>> It has a rather weird limitation in section 4, which says that you
can
> only use it on a "Microsoft Windows operating system product".
>>>>>> Since ReactOS is not Windows, that would mean we can't use it.
>>>>>> Please correct me if I'm wrong.
>>>>>>
>>>>>> Regards,
>>>>>> Alexander
>>>>>>
>>>>>> On Fri, Nov 29, 2013 at 02:58:51PM -0000, Ged Murphy wrote:
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> I know this has been discussed before, but should we not just bite
> the bullet and replace this driver with the Microsoft driver.
>>>>>>> The MS_LPL license allows it to be used in reactos, and it would
> certainly get rid of any unknowns and give us a reliable filesystem to
work
> from.
>>>>>>> http://code.msdn.microsoft.com/windowshardware/fastfat-File-Syste
>>>>>>> m-Driver-135bdf34/view/SourceCode
>>>>>>>
>>>>>>> Ged.
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: ros-diffs-bounces(a)reactos.org
>>>>>>> [mailto:ros-diffs-bounces@reactos.org] On Behalf Of
>>>>>>> ekohl(a)svn.reactos.org
>>>>>>> Sent: 29 November 2013 14:06
>>>>>>> To: ros-diffs(a)reactos.org
>>>>>>> Subject: [ros-diffs] [ekohl] 61145: [FASTFAT]
> FsdGetFsVolumeInformation: Return volume creation time.
>>>>>>> Author: ekohl
>>>>>>> Date: Fri Nov 29 14:05:43 2013
>>>>>>> New Revision: 61145
>>>>>>>
>>>>>>>
>>>>>>>
------------------------------
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
End of Ros-dev Digest, Vol 111, Issue 24
****************************************
Hi all,
Apart from the critical servers hosted in Germany, we can operate our
own network in Sweden by courtesy of Jan Blomqvist-Kinander.
Today, the infrastructure team has set up a new switch there, which is
meant to increase the network performance, allow a better intrusion
detection and offer more ports.
Most of our machines could be successfully moved to that switch, except
for Fezile. Due to unexpected networking problems, this machine became
unavailable even for us and needs to be rebooted manually. It's also one
of our older servers without an IPMI module, so we can't remotely reboot it.
The server outage affects the following services:
* iso.reactos.org
* doxygen.reactos.org
* cppcheck.reactos.org
* VMware Player Test slave
I'm very sorry for the additional downtime this has caused.
Once the server is up again, we'll do our best to prevent this from
happening again. Take my word that I'll write a report for the website
about the recent infrastructure changes, so you can get an idea of our
additional resources :)
With best regards,
Colin
Hi all,
In the process of improving the performance of our infrastructure, we
will upgrade the first of two servers this Saturday.
This will result in a downtime for the following services:
* SVN
* Mail and mailing lists
* BuildBot
* Testman
* GIT mirror
* File server at svn.reactos.org
* Compatibility Database
* ev.reactos.org
* Second nameserver
* RosKGB bot
The upgrade will in particular increase CPU performance as well as RAM
and HDD sizes, so we will have more resources available afterwards.
Our current server has served us well since 2009, so don't expect such
an upgrade to happen again in the next few years.
We're aware that this affects many core services, so we will do our best
to keep the downtime as low as possible. Our target is <12h.
Gladly, we have already done such an upgrade in the past, so it mainly
boils down to the speed of transferring files over the network.
Meanwhile, we apologize for the caused inconveniences.
With best regards and on behalf of the whole infrastructure team,
Colin Finck
Hey guys,
website seems to have some bigger problems with mySQL connection overload.
SQL ERROR [ mysqli ]
Too many connections [1040]
An sql error occurred while fetching this page. Please contact an administrator if this problem persists.
-------------------
PDOException: SQLSTATE[08004] [1040] Too many connections in lock_may_be_available() (line 167 of /srv/www/www.reactos.org/drupal/includes/lock.inc).
So administrator, I think this counts a s contacting you ^^
Greetings
Daniel "EmuandCo" Reimer
What exactly will be upgraded (table: model -> new_model)?
Pozdrawiam,
Adam "Saibamen" Stachowicz
Administrator it-maniak.pl
2013/11/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. Server downtime on Saturday (Colin Finck)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Nov 2013 11:08:46 +0100
> From: Colin Finck <colin(a)reactos.org>
> To: ros-general(a)reactos.org, ReactOS Development List
> <ros-dev(a)reactos.org>
> Subject: [ros-dev] Server downtime on Saturday
> Message-ID: <528DDBAE.9070804(a)reactos.org>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Hi all,
>
> In the process of improving the performance of our infrastructure, we
> will upgrade the first of two servers this Saturday.
> This will result in a downtime for the following services:
>
> * SVN
> * Mail and mailing lists
> * BuildBot
> * Testman
> * GIT mirror
> * File server at svn.reactos.org
> * Compatibility Database
> * ev.reactos.org
> * Second nameserver
> * RosKGB bot
>
> The upgrade will in particular increase CPU performance as well as RAM
> and HDD sizes, so we will have more resources available afterwards.
> Our current server has served us well since 2009, so don't expect such
> an upgrade to happen again in the next few years.
>
> We're aware that this affects many core services, so we will do our best
> to keep the downtime as low as possible. Our target is <12h.
> Gladly, we have already done such an upgrade in the past, so it mainly
> boils down to the speed of transferring files over the network.
> Meanwhile, we apologize for the caused inconveniences.
>
> With best regards and on behalf of the whole infrastructure team,
>
> Colin Finck
>
>
>
> ------------------------------
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
> End of Ros-dev Digest, Vol 111, Issue 16
> ****************************************
>
Hi,
These failures were due to work on the local network. They should be
fixed by now and ISOs uploaded.
If you catch a missing ISO, please re-issue a build.
Sorry for the caused inconvenience.
With my best regards,
On 11/18/2013 04:36 PM, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/4713
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_1
>
> Build Reason: scheduler
> Build Source Stamp: 61039
> Blamelist: tkreuzer
>
> BUILD FAILED: failed shell
>
> sincerely,
> -The Buildbot
>
>
>
>
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hi all,
This is an acknowledgment and informative email.
Since we migrated the ReactOS website to Drupal, you all have spotted
critical performances issues. We did our best to address most of them in
the following days to ensure smooth browsing on the website.
Unfortunately we could not fix them all.
Even worse, nowadays, ReactOS website faces a kind of "shutdown"
everyday (approximately between 2:45 AM CET and 4:45 AM CET). This is a
really long and critical downtime that affects mainly US users due to
timezones.
Be sure we are aware about it.
Unfortunately, this is not something we can fix from a day to the
following. This is due to our backup policies that completely lock the
MySQL server to ensure consistent backups.
We are currently working on getting this fixed as fast as possible. But
this will require (besides the rest) a two hardware upgrades on our
infrastructure.
Indeed, Drupal stresses our infrastructure much more than old RosCMS.
And we have to fully rethink our web infrastructure and redistribute it,
which we cannot do at the moment due to hardware constraints. Upgrading
our hardware will be in our first steps (obviously, expect downtimes at
that moment). Then, we will finally be able to replicate our MySQL
server to perform load-balancing and prevent shutdowns on backup.
We, the sysadmins team and the website team, agreed on a plan about how
to enhance and strengthen the infrastructure, and thus fix all the
issues we are currently facing. This will take some time, but we are
working together to get ReactOS website back into a decent shape.
Be assured that we are doing our best to make your place nice.
Meanwhile, please forgive us the caused inconvenience.
With my best regards, on behalf of the guys working behind the scene,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hi.
This should be removed, we are not wine and I personally work "hard on"
getting wine todos fixed in ReactOS! This also breaks the DCE test.
Background, GvG and then the old guard back in the day thought the same way
as I do about this issue. We should count the todo's as failures and not
bypass these failues. Why? It may point to a critical bug that could break
functionality somewhere else. That was the reasoning then and I agree with
it. Cheating the tests is just plain cheating......
James
Hi James,
What do you have in mind when you write CORE-???? ?
Is it something related to http://jira.reactos.org/browse/CORE-7469 ?
Cheers,
Hermès
----------------------------------------------------------------------------
--------------------------
Author: jimtabor
Date: Wed Nov 13 17:21:41 2013
New Revision: 60974
URL: http://svn.reactos.org/svn/reactos?rev=60974&view=rev
Log:
- Wine had some fixups added since this was last synced. CORE-???? &
CORE-7574.
Modified:
trunk/rostests/winetests/user32/sysparams.c
Nice to see you committing, hto!
Regards,
Aleksey Bragin
On 02.11.2013 17:56, dgorbachev(a)svn.reactos.org wrote:
> Author: dgorbachev
> Date: Sat Nov 2 13:56:47 2013
> New Revision: 60832
>
> URL: http://svn.reactos.org/svn/reactos?rev=60832&view=rev
> Log:
> [CMAKE]
> Reduce the disk space needed to build ReactOS (disabled for LTCG builds - linker bug #15143).
>
> Modified:
> trunk/reactos/toolchain-gcc.cmake
>
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 31st of October, 19:00 UTC. Put that into your
calendars so you don't forget. That's the last day of this month too and
that's tomorrow!
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Pierre or Colin (depending who will handle this meeting) before
the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
Hi,
North of Europa is facing a major storm. Currently, it is hitting Sweden
where it is really violent.
Unfortunately, some of our servers are there as well. Our datacenter has
been affected (likely power issue) and two servers are currently offline
and cannot be rebooted remotely.
Our local sysadmin cannot make a move to the datacenter following the
authorities recommandations to stay at home.
So far, the following parts of our infrastructure are offline:
-> Doxygen
-> cppcheck
-> ISO download
-> ISO upload
-> VMware testbots
As a side effect, I will take the Linux builder & KVM testbot offline
given it is impossible to upload any ISO at the moment.
We will do our best to get the infrastructure back online as fast as
possible.
We will keep you informed.
We are sorry for the caused inconvenience.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
How can I build and install ReactOS on a new computer?
Can I install to a USB stick or to a 1.2 GB IDE hard drive in a USB 2.0 hard-drive enclosure?
Main hard drive is Western Digital Green 3 TB, GPT-partitioned.
I would have to build from FreeBSD or less likely NetBSD or Linux.
I downloaded the installation ISO for ReactOS 0.3.15, but it failed to boot, also failed to boot on an old computer.
I already have subversion (svn), built from FreeBSD ports.
Tom
> [-- Type: multipart/alternative, Encoding: 7bit, Size: 3.0K --]
> Content-Type: multipart/alternative; boundary=001a11c3c7dccc447f04e913cb34
> Content-Type: text/plain; charset=UTF-8
> You can find ready-to-use builds of recent SVN revisions at:
> https://www.reactos.org/getbuilds
> If you don't see builds for the latest, use the arrows to go back until you
> find one that has files.
> You can NOT install ReactOS on a USB hard drive, though.
> If you do want to build from source regardless, you should look at RosBE,
> although I'm not sure if it works well in FreeBSD, since I build from
> Windows.
Thanks for response.
Linux and the BSDs are not so fussy about where they are installed on,
USB stick is OK.
But I remember DOS, Windows and OS/2 were fussy.
Do you use MinGW in Windows?
MinGW, subversion, ninja and GCC are all available in FreeBSD ports collection.
>From what I read, I think ReactOS might not get along with USB 3.0 and GPT,
hence the desire to use a USB stick.
FreeDOS also is difficult to install, many failed attempts on my computer
perhaps related to modern hardware.
FAT32 file system is not really good for making use of today's big hard drives.
But keeping up with NTFS is difficult because NTFS is a moving target (I believe).
I really feel more at home now with Linux and FreeBSD than with DOS, Windows or OS/2.
Tom
Hello.
Just nitpicking a bit:
>> -target_link_libraries(ntvdm softx86 softx87 fast486)
>> +target_link_libraries(ntvdm fast486)
>> add_importlibs(ntvdm msvcrt user32 gdi32 kernel32 ntdll)
>> -add_dependencies(ntvdm softx86 softx87)
>> +add_dependencies(ntvdm fast486)
The call to add_dependencies is useless here, as a call to target_link_libraries adds an implicit dependency.
Regards
Jérôme
Jim, this and your other patch can never happen. It's ListEntry that can be NULL, but Property will never be (in fact, it will be negative number). Also, ListEntry should never be NULL anyway, otherwise it means the list head is corrupted.
Containing record is just math...not a dereference.
--
Best regards,
Alex Ionescu
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of jimtabor(a)svn.reactos.org
Sent: Tuesday, October 15, 2013 3:17 PM
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [jimtabor] 60683: [Win32ss] - Prevent a potential kernel exception.
Author: jimtabor
Date: Tue Oct 15 22:16:31 2013
New Revision: 60683
URL: http://svn.reactos.org/svn/reactos?rev=60683&view=rev
Log:
[Win32ss]
- Prevent a potential kernel exception.
Modified:
trunk/reactos/win32ss/user/ntuser/prop.c
Modified: trunk/reactos/win32ss/user/ntuser/prop.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/prop.c…
==============================================================================
--- trunk/reactos/win32ss/user/ntuser/prop.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/user/ntuser/prop.c [iso-8859-1] Tue Oct 15 22:16:31 2013
@@ -21,6 +21,7 @@
while (ListEntry != &Window->PropListHead)
{
Property = CONTAINING_RECORD(ListEntry, PROPERTY, PropListEntry);
+ if (!Property) break;
if (Property->Atom == Atom)
{
return(Property);
On 2013-10-16 00:14, jimtabor(a)svn.reactos.org wrote:
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/window…
> ==============================================================================
> --- trunk/reactos/win32ss/user/user32/windows/prop.c [iso-8859-1] (original)
> +++ trunk/reactos/win32ss/user/user32/windows/prop.c [iso-8859-1] Tue Oct 15 22:14:48 2013
> @@ -53,6 +53,7 @@
> for (i = 0; i < pWnd->PropListItems; i++ )
> {
> Property = CONTAINING_RECORD(ListEntry, PROPERTY, PropListEntry);
> + if (!Property) break;
> if (Property->Atom == Atom)
> {
> return(Property);
>
>
That can't happen unless the list is corrupt.
And even if the list contains a null pointer (which it's not supposed
to), ListEntry would be NULL, not Property.
Sorry
Sent from my Windows Phone
From: Aleksey Bragin
Sent: 14-10-2013 PM 02:41
To: ReactOS Development List
Subject: Re: [ros-dev] reactos.org is down
Z, don't take that too seriously
;-)
Regards,
Aleksey Bragin
On 14.10.2013 7:12, Zachary Gorden wrote:
> Please refrain from making demands of a non-profit, volunteer driven
> project. It's impolite bordering towards insulting to the people
> working on the project.
>
> On Sun, Oct 13, 2013 at 7:45 PM, Ameer Ali <ameerali.ma(a)gmail.com> wrote:
>> Again its happening....pls don't repeat..
>>
>> Sent from my Windows Phone
>> ________________________________
>> From: Pierre Schweitzer
>> Sent: 14-10-2013 AM 02:58
>> To: ros-dev(a)reactos.org
>> Subject: Re: [ros-dev] reactos.org is down
>>
>> We're back online.
>>
>> On 13/10/2013 22:51, Pierre Schweitzer wrote:
>>
>> The faulty server is being replaced at the moment.
>>
>> On 13/10/2013 19:52, Pierre Schweitzer wrote:
>>
>> Hi,
>>
>> this is known issue (which has been handled 13 minutes after it
>> happened - just for the record ;-)). Unfortunately, so far, it is not
>> going very well.
>>
>> This affects: www.reactos.org, jira.reactos.org, dev.reactos.org,
>> code.reactos.org, ns1.reactos.org (use NS2 for the moment).
>>
>> We're sorry for the caused inconvenience.
>>
>> With my best regards,
>> Pierre
>>
>> On 13/10/2013 18:20, ????????? wrote:
>>
>> reactos.org is down
>> --
>> ? ?????????? ???????????, ?????????.
>>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Good work buddies...
Sent from my Windows Phone
From: Aleksey Bragin
Sent: 09-10-2013 PM 06:37
To: ReactOS Development List
Subject: Re: [ros-dev] Branches status & cleanup
If he starts from the latter, then he would have more than enough money
to fund all ReactOS development and buy Microsoft Corp. :D
Regards,
Aleksey
On 09.10.2013 16:55, Hermès BÉLUSCA - MAÏTO wrote:
> Tip: order your priorities !!
>
> -----Message d'origine-----
> De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la
> part de Timo Kreuzer
> Envoyé : mercredi 9 octobre 2013 11:08
> À : ReactOS Development List
> Objet : Re: [ros-dev] Branches status & cleanup
>
> Am 09.10.2013 10:18, schrieb Thomas Faber:
>> On 2013-10-07 23:03, Aleksey Bragin wrote:
>>> GSoC_2011
>>> Five subbranches. What's their status? Were they all merged?
>> - Claudiu's and mine are fully merged.
>> - According to SVN I took the explorer_new fixes from Andrew's into
>> trunk last year ... I'll recheck whether that was everything.
>> - Timo's is unmerged and has some unmet dependencies IIRC.
>> - Giannis merged most or all of his, but he should know best if there's
>> anything useful in there still.
> Please keep my GSoC branch, it contains code for the font engine rewrite,
> which is still WIP and I plan to continue on it after the DIB rewrite branch
> is finished. (And after I fixed PSEH3, implemented PSEH for C++ and CLANG,
> fixed a dozen Jira issues, rewrote Mm and Cc and found a cure for cancer.)
>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Again its happening....pls don't repeat..
Sent from my Windows Phone
------------------------------
From: Pierre Schweitzer
Sent: 14-10-2013 AM 02:58
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] reactos.org is down
We're back online.
On 13/10/2013 22:51, Pierre Schweitzer wrote:
The faulty server is being replaced at the moment.
On 13/10/2013 19:52, Pierre Schweitzer wrote:
Hi,
this is known issue (which has been handled 13 minutes after it
happened - just for the record ;-)). Unfortunately, so far, it is not
going very well.
This affects: www.reactos.org, jira.reactos.org,
dev.reactos.org,code.reactos.org, ns1.reactos.org (use NS2 for the
moment).
We're sorry for the caused inconvenience.
With my best regards,
Pierre
On 13/10/2013 18:20, ????????? wrote:
reactos.org is down
--
? ?????????? ???????????, ?????????.
_______________________________________________
Ros-dev mailing
listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing
listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing
listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hello!
I would like to inject more life into our branches and hence need to
remove as much dead bodies from that area as possible. And I need your
feedback!
Please comment on that list. like - needs to be merged, useless, could
be deleted.
aicom-hardware-fun
"Branch for my hardware support work and other stuff". Last commit 17th
of May, 2010. Bring back Cromwell as a temporary USB stack until
mjmartin finishes the new one, Implement missing storage stack drivers
(storport, ataport, etc), Work more on the PnP manager.
Obsolete?
aicom-network-branch
Last commit was 4th of August, 2011. Another branch for networking
fixes. "If someone wants to delete aicom-network-fixes, they are welcome to"
alex-network-branch
Last commit was 24th of December, 2006. Some parts are still not merged.
What a shame!
arty-newcc
New CC implementation by arty. It stays.
arty-stable
Arty - do you need it? No problem in keeping it, if you need it.
arwinss
Aleksey - do you need it? Yes I do!! :-)
audio-bringup
Johannes? Last commit 26 of April, 2011.
c++-bringup
Very promising name and just one commit by jgardou, 8th of March, 2012.
Jerome?
cmake-bringup
I think we switched to CMake already. Any reason to keep this branch?
dib_rewrite
Timo's great work.
GSoC_2011
Five subbranches. What's their status? Were they all merged?
icu4ros-bringup
Empty branch. Amine, would you comment whether it's necessary?
iut-mmc
Pierre?
jcatena-branch
MSVC work. Needed?
kd++
By Hermes. I think, it's needed.
lean-explorer
Lean explorer by Martin Fuchs. Last touched in 2006.
nocc
Special "nocc" cache manager. It stays.
nslookup
I guess lsuggs gave up on that. But the idea was nice.
ntvdm
We all know [TheFlash]. Stable progress. Good work.
nyadav-audio-branch
Last commit dates to year 2011. Nyadav?
olpc
One awesome Laptop Per one awesome Child. We can keep it a bit more for
historical reasons.
pierre-fsd
Pierre's presumably great work.
reactx
GreatLord's work on DirectX. Status unknown. Sylvain?
ros-amd64-bringup
Timo - is it still relevant, or did you already merge it in trunk?
ros-csrss
Last commit says "Ready for merging (TM) :)". ORLY? :-)
shell32_new-bringup
Mr. Mihail, you around? Anyone knows state of that work?
sspi-bringup
Samuel? What's with that branch?
tcp-rewrite-branch
LWIP. I think it's integrated into trunk long time ago? Last commit -
year 2010
the-real-msvc
KJK's work which stopped in 2008. Anyone could comment whether there is
anything we haven't achieved with CMake yet?
Tree-restructure-test
Playground for restructuring the tree. "Let's reshuflle the files and
directories and that makes our OS more stable and usable". Last commit
was almost exactly 3 years ago.
usb-bringup-trunk
Johannes? Still need that?
vs_jc
jjones? Do you plan to continue working on that?
wlan-bringup
Cameron, how's it going?
And the problems that were present at that time (rbuild to cmake migration
etc...) are solved now...
H.
-----Message d'origine-----
De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la
part de Ged Murphy
Envoyé : mardi 8 octobre 2013 19:38
À : 'ReactOS Development List'
Objet : Re: [ros-dev] Branches status & cleanup
Yes! This is such an obvious improvement, I'm surprised it's still not
widely accepted.
An epic mail from Timo explaining the current tree layout
https://www.reactos.org/archives/public/ros-dev/2010-July/013278.html
For anyone still interested in reading our rants, here's the start of the
original mailing list convo
https://www.reactos.org/archives/public/ros-dev/2010-July/013257.html
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On
Behalf Of Hermès BÉLUSCA - MAÏTO
Sent: 08 October 2013 17:47
To: 'ReactOS Development List'
Subject: [SPAM]Re: [ros-dev] Branches status & cleanup
> Tree-restructure-test
> Playground for restructuring the tree. "Let's reshuflle the files and
directories and that makes our OS more stable and usable". Last commit was
almost exactly 3 years ago.
I'm personally very interested in this thing (cf.
http://www.reactos.org/forum/viewtopic.php?p=102258&sid=ef8d6c9a27f9e3800b7d
ff87afdc5919 and OF COURSE http://www.reactos.org/wiki/Techwiki:File_Layout
) which aims at bringing modularity.
Cheers,
Hermès.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
You are implementing part of ReactOS so you can't just silently
relicense your code in one commit to a license which is incompatible
with ReactOS aims and goals.
At the very least, I would appreciate a discussion with our team
regarding this before doing such commits.
Please revert. The runtime linking exception was added for a reason, not
for amusement or RMS trolling. RMS is unhappy either way (not that I
care about his opinion :).
Regards,
Aleksey Bragin
On 01.10.2013 2:01, aandrejevic(a)svn.reactos.org wrote:
> Author: aandrejevic
> Date: Mon Sep 30 22:01:38 2013
> New Revision: 60485
>
> URL: http://svn.reactos.org/svn/reactos?rev=60485&view=rev
> Log:
> [SOFT386]
> Change the license of Soft386 to GPLv2. The previous license was also
> GPLv2, but it had a runtime linking exception. The new license is the
> original GPLv2 with no exceptions.
>
>
> Added:
> branches/ntvdm/lib/soft386/COPYING (with props)
> Modified:
> branches/ntvdm/lib/soft386/common.c
> branches/ntvdm/lib/soft386/common.h
> branches/ntvdm/lib/soft386/common.inl
> branches/ntvdm/lib/soft386/opcodes.c
> branches/ntvdm/lib/soft386/opcodes.h
> branches/ntvdm/lib/soft386/opgroups.c
> branches/ntvdm/lib/soft386/opgroups.h
> branches/ntvdm/lib/soft386/soft386.c
>
I didn't deny anyone anything. I'm not the author of the code you just
"fixed" (you missed the brackets btw). I see that you were corrected by
him in r60473.
Regards,
Amine.
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 26th of September, 19:00 UTC. Put that into your
calendars so you don't forget. That's tomorrow!
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Pierre before the meeting started to get one. And thanks Pierre
for handling technical side of the meeting nearly all the time.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
Give contact details for immediate fund transfer...
Sent from my Windows Phone
-----Original Message-----
From: Pierre Schweitzer
Sent: 22-09-2013 PM 04:31
To: ReactOS Development List
Subject: Re: [ros-dev] reactos.org is down
Your offer to pay a full-time sysadmins team (4 is fine), with on-call
time for the next year has been well received.
Thanks as well to offer us two more machines to ensure this never
happens again.
Please contact ReactOS Deutschland e.V. for fund transfert information.
Such considerable efforts are never forgotten.
On 22/09/2013 12:39, Ameer Ali wrote:
> Makesure that reactos.org site is available at everytime.Many activity got
> pending due to this. Don't repeat.
>
> Provide action plan for the same.urgent
>
> Sent from my Linux Phone
> ------------------------------
> From: Pierre Schweitzer
> Sent: 22-09-2013 PM 03:26
> To: ros-dev(a)reactos.org
> Subject: Re: [ros-dev] reactos.org is down
>
> Hi,
>
> we're currently getting back online.
>
> Sorry for the inconvenience caused by this downtime.
>
> With my best regards,
>
> On 22/09/2013 11:25, Александр wrote:
>
> reactos.org is down
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Makesure that reactos.org site is available at everytime.Many activity got
pending due to this. Don't repeat.
Provide action plan for the same.urgent
Sent from my Linux Phone
------------------------------
From: Pierre Schweitzer
Sent: 22-09-2013 PM 03:26
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] reactos.org is down
Hi,
we're currently getting back online.
Sorry for the inconvenience caused by this downtime.
With my best regards,
On 22/09/2013 11:25, Александр wrote:
reactos.org is down
--
С наилучшими пожеланиями, Александр.
_______________________________________________
Ros-dev mailing
listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
I think a call to IoReleaseCancelSpinLock should be balanced with a call to
IoAcquireCancelSpinLock somewhere in the npfs_new code, however, looking at:
http://git.reactos.org/?p=reactos.git
<http://git.reactos.org/?p=reactos.git&a=search&h=HEAD&st=grep&s=IoAcquireCa
ncelSpinLock> &a=search&h=HEAD&st=grep&s=IoAcquireCancelSpinLock
I dont see any call to IoAcquireCancelSpinLock in npfs_new. Can someone
explain to me, why ?
Hermès
Author: tfaber
Date: Fri Sep 20 06:49:21 2013
New Revision: 60231
URL: http://svn.reactos.org/svn/reactos?rev=60231&view=rev
Log:
[NPFS]
- Release cancel spinlock in NpCancelListeningQueueIrp
Modified:
trunk/reactos/drivers/filesystems/npfs_new/statesup.c
Modified: trunk/reactos/drivers/filesystems/npfs_new/statesup.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/npfs_ne
w/statesup.c?rev=60231&r1=60230&r2=60231&view=diff
============================================================================
==
--- trunk/reactos/drivers/filesystems/npfs_new/statesup.c [iso-8859-1]
(original)
+++ trunk/reactos/drivers/filesystems/npfs_new/statesup.c [iso-8859-1] Fri
Sep 20 06:49:21 2013
@@ -20,6 +20,8 @@
NpCancelListeningQueueIrp(IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp)
{
+ IoReleaseCancelSpinLock(Irp->CancelIrql);
+
FsRtlEnterFileSystem();
NpAcquireExclusiveVcb();
On 2013-09-18 01:02, hbelusca(a)svn.reactos.org wrote:
> Added:
> branches/ntvdm/lib/soft386/common.inl (with props)
It's a header file. Can you name it .h please to not break syntax
highlight? Thanks.
Timo originally proposed this but I'd like to actually see the
proposal implemented. When working on ReactOS, I'd like developers to
create tickets in jira that their commits can then reference. For
example, Amine's wine syncs could have a ticket with the title "Wine
sync with version 1.x.y" or Alex's NPFS rewrite could have a ticket
with the title "New NPFS driver" and the relevant commits can have the
ticket number in them. This way when time comes for the changelog, all
that needs to be done is gather a list of all tickets closed before
the branch, no more of the digging through thousands of commit
messages crap.
Hello,
I am new to the reactos project.
I think I found a task where I can contribute :
http://www.reactos.org/wiki/Printing
But I don't know if someone else work on this task ?
Thank you
Loïc Maury
Hi All!!!
I'm not in the position to handle anymore bug reports other than the
only ones I'm working on now. Please do not assign new bugs to me!
Thanks,
James
Hi,
two major improvements have been done to testbots today, linked with
commit r59985:
http://svn.reactos.org/svn/reactos?view=revision&revision=59985
Thanks to Olaf, the Patch testbot has been extended that way: if you
specify parameter name windll with value yes, then ntdll from win2k3
will be used for the tests of your patch.
If you specify patch ID: 0, then unpatched revision will be tested.
In parallel, I've been working on Linux VMware testbot, that now has a
second testbot. This one is triggered on each commit and will test
ReactOS trunk with ntdll from win2k3. The results are uploaded to
testman. You can see the results with first attempt:
http://reactos.org/sites/all/modules/reactos/testman/compare.php?ids=19420,…
So far, we didn't include kernel32.dll nor npfs.sys due to the inability
of regtests to work with them. This will come later on.
Thanks to all for your great work permitting this major step for the
ReactOS project.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hey Guys,
I'll be in Montreal on October 2nd (Wednesday) giving a tech talk about
ReactOS, for about 2 hours. I intend to go over everything from development
to infrastructure (translation, testing, etc).
Are there any materials and/or suggestions from previous talks available
anywhere? Any set of tools/games/apps you recommend I try out?
--
Best regards,
Alex Ionescu
Me too have same opinion...
Sent from my windows Phone
From: Aleksey Bragin
Sent: 06-09-2013 AM 01:09
To: ReactOS Development List
Subject: Re: [ros-dev] Google Montreal Tech Talk
On 05.09.2013 23:00, Sven Barth wrote:
> On 05.09.2013 16:36, Александр wrote:
>> Tell them about http://www.youtube.com/watch?v=BzJTZY54r0I training
>> course called "operating systems" based on Reactos in Moscow State
>> Technical University by Aleksey Bragin. Also tell them about 2000 pages
>> of Chinese textbook devoted to Reactos 1)
>> http://yadi.sk/d/yRbwE6-23NqQu 2) http://yadi.sk/d/CxgVpVzS3G-GQ
>
> Pity that I understand neither Russian nor Chinese...
>
> @Aleksey: If you allow I have two small suggestions regarding your
> style of lecture based on the linked video (I don't know whether this
> already changed since the time of recording though):
> - try to look towards your students
> - please keep your hands out of your pockets
> As a student I definitely prefer presenters that respect these two
> points (and yes, I'm aware that this can be hard)
>
> Regards,
> Sven
Thanks Sven, I improved after watching the first recorded video of the
lecture myself, and tried to "fix" those issues in the next lectures.
Next time to practice would be 2014 spring when I am reading the same
course to the new 2nd year students.
Regards,
Aleksey Bragin
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
I just wanted to say that this is just amazing. Being able to debug
ReactOS with "reference" low-level DLLs is great, but being able to
debug ReactOS ntdll and kernel32 when running them in reference
environment (that is, Windows 2003) is even better!
Indeed, I think, having a special testbot for this would be very beneficial.
Regards,
Aleksey
On 04.09.2013 11:28, ion(a)svn.reactos.org wrote:
> Author: ion
> Date: Wed Sep 4 07:28:15 2013
> New Revision: 59985
>
> URL: http://svn.reactos.org/svn/reactos?rev=59985&view=rev
> Log:
> This commit, in my opinion, marks an important milestone in ReactOS development. One is now able to boot to desktop, launch applications, download through the application manager, play solitaire, minesweeper, launch Task Manager, etc... by using an unmodified Windows 2003 kernel32.dll binary (and, until our NPFS driver is fixed, the unmodified Windows 2003 NPFS driver). Additionally, one is able to achieve the same by booting with an unmodified Windows 2003 ntdll.dll, including a combination of both. The capability to mix-and-match components such as kernel32 and ntdll, at the heart of the system, will allow to better understand apitest failures (just as Wine has long had the capability to use Windows DLLs instead). With these two building blocks, additional Windows 2003 DLLs can be dropped in/tested, etc, and where failures are seen, a likely component can now be blamed. Furthermore, debugging with public symbols for these DLLs is now possible with WinDBG (in fact, this is how many bugs were fixed in this attempt). Many issues already exist when running with this combination FYI, for example, I was not able to launch any installers (tested Firefox and MIRC). This already demonstrates either missing functionality or ReactOS-specific functionality in components which depend on kernel32. I suspect the next step is infrastructure work to get special patchbot/builders to try and report back winetest results, and for additional DLLs to be "ported"/made to work. On a final note, this mixing and matching has benefits on both ends -- it's now likely that ReactOS' ntdll can run on Server 2003, at least far enough to get to Explorer or Task Manager. Running apitests on Server 2003 with and without reactos DLLs should also easily identify if certain DLLs are directly to blame for certain regressions/failures. </end excited rant>
> [BASESRV]: Allocate the INI mappings from the right heap.
>
> Modified:
> trunk/reactos/subsystems/win/basesrv/init.c
>
> Modified: trunk/reactos/subsystems/win/basesrv/init.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win/basesrv/ini…
> ==============================================================================
> --- trunk/reactos/subsystems/win/basesrv/init.c [iso-8859-1] (original)
> +++ trunk/reactos/subsystems/win/basesrv/init.c [iso-8859-1] Wed Sep 4 07:28:15 2013
> @@ -139,7 +139,7 @@
> BaseSrvInitializeIniFileMappings(IN PBASE_STATIC_SERVER_DATA StaticServerData)
> {
> /* Allocate the mapping blob */
> - BaseSrvIniFileMapping = RtlAllocateHeap(BaseSrvHeap,
> + BaseSrvIniFileMapping = RtlAllocateHeap(BaseSrvSharedHeap,
> HEAP_ZERO_MEMORY,
> sizeof(*BaseSrvIniFileMapping));
> if (BaseSrvIniFileMapping == NULL)
>
>
Hi Alex!
The stack guards prevent excessive recursions without throwing exceptions
and just kills the message loop by returning false. Removing them could
regress some misbehaving applications. Only one comes to mind, java
installer.
Thanks,
James
Nice!
@ Benedikt: You have some bug reports on Jira concerning Paint, which need
some love :) (CORE-5641, CORE-5645, CORE-5644 and CORE-5954) . I don't know
whether your commit fixes one of them.
Hermès
----------------------------------------------------------------------------
----------------------------------------------------------
Author: bfreisen
Date: Sun Sep 1 20:13:15 2013
New Revision: 59954
URL: http://svn.reactos.org/svn/reactos?rev=59954&view=rev
Log:
[PAINT]
* Stretch/Skew dialog fully implemented (skewing not yet functional), please
check translations
* pre Windows Vista MSPaint palette selectable via menu entry
* Attributes dialog supports setting width and height in inches and cm also
* drawing functions improved
* some variables grouped into structs
* Changed SendMessage(... WM_PAINT ...) into InvalidateRect(...), this is
the way it should be and it fixes half of the repainting bugs
Added:
[...]
Hi,
I have some great icon with me....
If U request I will give for free
Sent from my linux Phone
From: Colin Finck
Sent: 31-08-2013 PM 03:36
To: ros-dev(a)reactos.org
Subject: [ros-dev] Easy job for enhancing our Explorer!
Hi all!
As suggested in the meeting on Thursday, we need someone to create
replacements for all icons used in Windows Explorer. Just have a look at
this screenshot of Giannis' recent work to get an idea:
http://i.imgur.com/WzxVn7V.png
It definitely looks promising, but we obviously can't release it with
the XP icons ;)
Gladly, the Tango icon library contains a lot of great icons, which may
already be suitable for Explorer. Others could be created easily when
mixing several icons. For example, the icon for the "Folders" button in
Explorer can be created out of two simple folders, and a single folder
icon is definitely present in Tango. This only requires basic knowledge
of Inkscape (www.inkscape.org).
To give you another example: I already needed such "mixed" icons in my
PeopleMap. I've released my modified SVG files here:
http://svn.reactos.org/svn/web/trunk/resources/peoplemap/?pathrev=700
Apart from the fairly simple Inkscape task, the icons need to be
properly converted to ICO files in all required sizes. Giannis or other
shell guys can probably tell you about the sizes we need.
At least, this requires a proper icon editor with support for 24/32 bit
icons (used to be a problem in the past, don't know if it still is).
For just creating ICO files out of existing PNG files, I had good
experiences with "@icon sushi" (http://www.towofu.net/soft/e-aicon.php).
So, there we have it: A job for enhancing our Explorer which doesn't
even need a developer! :)
If I had time for it, I'd probably do it myself, but I'm pretty sure
there are other interested people as well.
Cheers,
Colin
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Hi all!
As suggested in the meeting on Thursday, we need someone to create
replacements for all icons used in Windows Explorer. Just have a look at
this screenshot of Giannis' recent work to get an idea:
http://i.imgur.com/WzxVn7V.png
It definitely looks promising, but we obviously can't release it with
the XP icons ;)
Gladly, the Tango icon library contains a lot of great icons, which may
already be suitable for Explorer. Others could be created easily when
mixing several icons. For example, the icon for the "Folders" button in
Explorer can be created out of two simple folders, and a single folder
icon is definitely present in Tango. This only requires basic knowledge
of Inkscape (www.inkscape.org).
To give you another example: I already needed such "mixed" icons in my
PeopleMap. I've released my modified SVG files here:
http://svn.reactos.org/svn/web/trunk/resources/peoplemap/?pathrev=700
Apart from the fairly simple Inkscape task, the icons need to be
properly converted to ICO files in all required sizes. Giannis or other
shell guys can probably tell you about the sizes we need.
At least, this requires a proper icon editor with support for 24/32 bit
icons (used to be a problem in the past, don't know if it still is).
For just creating ICO files out of existing PNG files, I had good
experiences with "@icon sushi" (http://www.towofu.net/soft/e-aicon.php).
So, there we have it: A job for enhancing our Explorer which doesn't
even need a developer! :)
If I had time for it, I'd probably do it myself, but I'm pretty sure
there are other interested people as well.
Cheers,
Colin
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 29th of August, 19:00 UTC. Put that into your
calendars so you don't forget.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
>[ADVAPI32/SERVICES]: Windows services (as per MSDN and testing) must
always get at least one parameter -- the service name, in the argument
vector. However, in ReactOS, unless optional custom parameters were sent
(when starting a service), services got 0 parameters and a NULL argument
vector. Since services on Windows know this is impossible, many
dereference the vector without checking for NULL (including Windows
Svchost.exe). Either way, it's bogus for us not ever sending the name as
the first parameter. So I fixed ScBuildUnicodeArgsVector to always
either pre-pend the service name (if the caller gave us some parameters
already), or do use the name as the sole parameter (if the caller sent
none). This now works as on Windows, and should greately help with 3rd
party service compatibility.
>***NOTE THAT I ONLY DID THIS FOR UNICODE. I DID NOT BOTHER TO FIX THE
ANSI VERSION. ERIC KOHL, PLEASE REVIEW & FIX AS APPROPRIATE***
Alex,
if you have the time to rewrite svchost, you also have the time to fix
the little piece of ansi boredom! Finish the things you start!!!! Do not
stop right in the middle and leave the boring parts to others!!! FINISH
IT YOURSELF!!!!
PS: Btw, you might want to have a look at YOUR ntoskrnl rewrite! CM is
still unfinished! Finish it before you open yet another can of worms!
Regards,
Eric
\o/
And now please also remove the use of the OBJECT_HEADER structure in
win32k ;-)
Am 14.08.2013 13:02, schrieb fireball(a)svn.reactos.org:
> Author: fireball
> Date: Wed Aug 14 11:02:08 2013
> New Revision: 59733
>
> URL: http://svn.reactos.org/svn/reactos?rev=59733&view=rev
> Log:
> [WIN32K]
> - Do not use a internal section object structure type, it's just not necessary and win32k should not ever need to access its fields directly.
>
>
I don't really like this. Maybe only do this on the build server, or at
least don't do it to kernel code. "Measurable" difference in performance
doesn't really mean much on an OS that does not have any performance
infrastructure, but trust me, there's a difference between O1 and O2.
Best regards,
Alex Ionescu
On Wed, Jul 31, 2013 at 6:04 AM, <akhaldi(a)svn.reactos.org> wrote:
> Author: akhaldi
> Date: Wed Jul 31 13:04:38 2013
> New Revision: 59598
>
> URL: http://svn.reactos.org/svn/reactos?rev=59598&view=rev
> Log:
> [CMAKE/GCC]
> * Compile debug builds using -O1 instead of -Os. This results in faster
> compilation time with no measurable difference in runtime performance
> according to tests.
> CORE-7374 #resolve #comment Committed in r59598.
>
> Modified:
> trunk/reactos/cmake/config.cmake
>
> Modified: trunk/reactos/cmake/config.cmake
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/config.cmake?rev=595…
>
> ==============================================================================
> --- trunk/reactos/cmake/config.cmake [iso-8859-1] (original)
> +++ trunk/reactos/cmake/config.cmake [iso-8859-1] Wed Jul 31 13:04:38
> 2013
> @@ -10,7 +10,7 @@
> set(TUNE "i686" CACHE STRING
> "Which CPU ReactOS should be optimized for.")
>
> -set(OPTIMIZE "1" CACHE STRING
> +set(OPTIMIZE "4" CACHE STRING
> "What level of optimization to use.
> 0 = off
> 1 = Default option, optimize for size (-Os) with some additional options
>
>
>
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 25th of Julu, 19:00 UTC. Put that into your
calendars so you don't forget.
I will handle the technical side of the meeting and you will get your
login credentials shortly before the meeting. If someone still is not
getting passwords sent before a meeting - please email Colin or Pierre
before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (preferably send them to me before the meeting starts).
Regards,
Aleksey Bragin
Hi,
For all TSVN users: the new version 1.8.0 is broken. Merging doesn't
work and aborts once you get a conflict. I had to install a nightly to
make that work.
Also: it uses a new working copy format, which is incompatible with
older svn versions, like the one we use in RosBE. Which you would also
need to update.
Therefore I suggest to not update it yet, unless you really know what
you are doing. I don't want to hear complaints later ;-)
Timo
Am 30.06.2013 15:11, schrieb hbelusca(a)svn.reactos.org:
> weird indentation made by a mix of tabs / spaces which take either 4 or 8 or even (!!) 2 spaces per indentation level
That is called GNU coding style.
You should get a copy of the GNU coding standards.
And then treat it the way Linus T. suggests ;-)
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 27th of June, 19:00 UTC. And that's tomorrow!
Put that into your calendars so you don't forget.
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords will
be emailed to you shortly before the meeting starts, and they are going
to be different once again as they are not stored in any database.
Hopefully it's not much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
Hi All,
A few months ago, an SVN branch, vs_jc, was created so that I could
experiment with manual creation of Visual Studio solution. I am ready to
start putting files into it, but before I do, I would like to get it synced
with the trunk. Unfortunately, I am not very experienced with SVN (more like
hopelessly ignorant), and Id like to avoid making a mess if possible. I was
hoping that someone could sit with me for the 10-15 minutes that would be
needed to get it right so that I dont make a mess. Hermès was helping me
yesterday do a merge, but he seems to be out-of-pocket at the moment, and
Id rather not wait, as I am blocking the work of others.
The merge generated a lot of conflicts, and I see no option on Tortoise SVN
menu to resolve them, and I have tried 6 or 7 times myself to do a merge,
each time not being clear on what I am doing. I would have no problem
whatsoever blowing away vs_jc and simply branching HEAD-of-trunk and
starting over, as there is currently nothing that I put in vs_jc that is of
value.
Cheers!
-JC
That is still not correct. MM_DECOMMIT (which should be aliased as
MM_GUARDPAGE) is 0x10.
BUT, this is only a guardpage, if 0x8, aka MM_NOCACHE is not set.
it's like this:
Protection & 0x18 ==
0x00: normal
0x08: uncached
0x10: guard page
0x18: write combined
see http://www.reactos.org/wiki/Techwiki:Memory_Protection_constants
Am 16.06.2013 22:37, schrieb dreimer(a)svn.reactos.org:
> Author: dreimer
> Date: Sun Jun 16 20:37:04 2013
> New Revision: 59238
>
> URL: http://svn.reactos.org/svn/reactos?rev=59238&view=rev
> Log:
> logical 'and' applied to non-boolean constant
> Reviewed by Thomas Faber and asked for commit, so blame him!
> CORE-7207 #resolve #comment Fixed!
>
> Modified:
> trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] Sun Jun 16 20:37:04 2013
> @@ -647,7 +647,7 @@
> (EndAddress >= ((PMMVAD_LONG)Vad)->u3.Secured.StartVpn))
> {
> /* Guard page? */
> - if (ProtectionMask && MM_DECOMMIT)
> + if (ProtectionMask & MM_DECOMMIT)
> {
> DPRINT1("Not allowed to change protection on guard page!\n");
> return STATUS_INVALID_PAGE_PROTECTION;
>
>
>
( end of the message) , and its more elegant than many (str[i] !=
prefix[i] || ) instructions.
Maybe youre criticizing this change because of performances reasons ?
Cheers
Hermès
De : Hermès BÉLUSCA - MAÏTO [mailto:hermes.belusca@sfr.fr]
Envoyé : lundi 3 juin 2013 11:10
À : 'ReactOS Development List'
Objet : RE: [ros-dev] [ros-diffs] [hbelusca] 59165: [RTL] Use
RtlPrefixUnicodeString.
It was suggested by Thomas Faber, during some fixes of path.c
De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la
part de Alex Ionescu
Envoyé : lundi 3 juin 2013 04:33
À : ReactOS Development List
Cc : Linda Wang
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 59165: [RTL] Use
RtlPrefixUnicodeString.
You should realize there's sometimes a reason why code doesn't use an
existing helper function. Among some very good bug fixes and patches, you
really seem to love changing code just for the sake of changing code.
Best regards,
Alex Ionescu
On Sun, Jun 2, 2013 at 3:51 PM, <hbelusca(a)svn.reactos.org> wrote:
Author: hbelusca
Date: Sun Jun 2 22:51:24 2013
New Revision: 59165
URL: http://svn.reactos.org/svn/reactos?rev=59165
<http://svn.reactos.org/svn/reactos?rev=59165&view=rev> &view=rev
Log:
[RTL]
Use RtlPrefixUnicodeString.
Modified:
trunk/reactos/lib/rtl/path.c
Modified: trunk/reactos/lib/rtl/path.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/path.c?rev=59165
<http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/path.c?rev=59165&r
1=59164&r2=59165&view=diff> &r1=59164&r2=59165&view=diff
============================================================================
==
--- trunk/reactos/lib/rtl/path.c [iso-8859-1] (original)
+++ trunk/reactos/lib/rtl/path.c [iso-8859-1] Sun Jun 2 22:51:24
2013
@@ -479,13 +479,19 @@
/* Capture input string */
CapturedDosName = *DosName;
- /* Check for \\?\ form */
- if ((CapturedDosName.Length <= RtlpWin32NtRootSlash.Length) ||
- (CapturedDosName.Buffer[0] != RtlpWin32NtRootSlash.Buffer[0]) ||
- (CapturedDosName.Buffer[1] != RtlpWin32NtRootSlash.Buffer[1]) ||
- (CapturedDosName.Buffer[2] != RtlpWin32NtRootSlash.Buffer[2]) ||
- (CapturedDosName.Buffer[3] != RtlpWin32NtRootSlash.Buffer[3]))
- {
+ /* Check for the presence of the NT prefix "\\?\" form */
+ if (RtlPrefixUnicodeString(&RtlpWin32NtRootSlash, &CapturedDosName,
FALSE))
+ {
+ /* NT prefix is contained in the path */
+
+ /* Use the optimized path after acquiring the lock */
+ QuickPath = TRUE;
+ NewBuffer = NULL;
+ }
+ else
+ {
+ /* NT prefix is not contained in the path */
+
/* Quick path won't be used */
QuickPath = FALSE;
@@ -497,12 +503,6 @@
NewBuffer = RtlAllocateHeap(RtlGetProcessHeap(), 0, MaxLength);
DPRINT("MaxLength: %lx\n", MaxLength);
if (!NewBuffer) return STATUS_NO_MEMORY;
- }
- else
- {
- /* Use the optimized path after acquiring the lock */
- QuickPath = TRUE;
- NewBuffer = NULL;
}
/* Lock the PEB and check if the quick path can be used */
Revisions >= 59161 are fine (before starting with 59152 they are broken
- known).
This is only due to a VMware testbot internal failure. This is now fixed.
Sorry for the flood.
On 03/06/2013 00:28, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/985
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_2
>
> Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger)
> Build Source Stamp: 59161
> Blamelist:
>
> BUILD FAILED: failed test
>
> sincerely,
> -The Buildbot
>
>
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hi,
the Linux builder RosBE has been upgraded to latest 2.1. It keeps using ninja for builds.
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 30th of May, 19:00 UTC. And that's today!
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords will
be emailed to you shortly before the meeting starts, and they are going
to be different once again as they are not stored in any database.
Hopefully it's not much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
Hi,
Please note that r59047 broke VMware testbot. It times out in
setupapi:install and fails to restart afterwards.
Regards,
Pierre
On 20/05/2013 15:01, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/869
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_2
>
> Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger)
> Build Source Stamp: 59050
> Blamelist:
>
> BUILD FAILED: failed test
>
> sincerely,
> -The Buildbot
>
>
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
The following tests are introducing several bugs/regressions:
[ros-diffs]
[ekohl] 59021: [SYSSETUP] Enable the restore privilege before the call
to NtUnloadKey. Disable it immediately after the call to NtUnloadKey.
ekohl at svn.reactos.org
^This one introduces a potential regression at:
user32:clipboard From 49216 tests executed, aftwerdars 49208 (-8)shell32:appbar. From 61 test executed, afterwards 58
[ros-diffs]
[ekohl] 59022: [FASTFAT] Allow only readonly, hidden, system and
archive files attributes to be set for existing files. Other file
attributes must be ignored. This fixes several tests.
ekohl at svn.reactos.org
^This introduces a whole bunch of regressions easily spoted.
ole32:storage32oleaut32:typelibregedit:regeditsetupapi:miscsetupapi:parserEtc,Etc
[ros-diffs]
[ekohl] 59023: [FASTFAT] Implement a special case for existing files
which are opened using the FILE_OVERWRITE or FILE_OVERWRITE_IF file
disposition: New file attributes must be ORed with the exist...
ekohl at svn.reactos.org
^The following regresses:
zz_notepad++_6.1.2:1.installzz_notepad++_6.1.2:2.SaveAsDesktopzz_notepad++_6.1.2:3.OpenDocumentzz_notepad++_6.1.2:4.Ctrl-F.FindDialogzz_notepad++_6.1.2:5.Send_InputAmong others
Comparison chart: http://www.reactos.org/sites/all/modules/reactos/testman/compare.php?ids=17…
Hi,
due to critical load issues on reactos.org, the webserver has been taken
down now for an extra maintenance to address the issues.
Affected services are the following: reactos.org, doxygen.reactos.org
(still reachable but slow), jira.reactos.org (no auth), code.reactos.org
(no auth).
We cannot provide any ETA for the end of the maintenance.
We are sorry for the caused inconveniences.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
On 2013-05-13 15:05, ekohl(a)svn.reactos.org wrote:
> Status = NtReplyWaitReceivePort(AuthPortHandle,
> (PVOID*)&LogonContext,
> - &ReplyMsg->h,
> - &RequestMsg.h);
> + (PPORT_MESSAGE)ReplyMsg,
> + (PPORT_MESSAGE)&RequestMsg);
As the Guy Who Officially Hates Casts™, I have to ask: wasn't the
previous version better for type safety? With the cast, an additional
[or missing] & can slip in and the code will compile without complaint.
Best,
Thomas
Hey Pierre!
Nice patch series, that takes ReactOS nearer to being secure. A remark though :
> /*
> - * enable the SeSystemtimePrivilege privilege
> + * Call SetLocalTime twice to ensure correct results
> */
> + Ret = SetLocalTime(&SetupData->SystemTime) &&
> + SetLocalTime(&SetupData->SystemTime);
This is a bit confusing, and the comment doesn't really help. Why would calling the function twice ansure correct result ? Also, this is likely to be optimized away by the compiler, or at least produce a report in static code analysers.
I know this isn't pure chance. Any hint as to why you wrote it like this ?
Cheers
Jérôme
Small nit-pick:
.\reactos\reactos\tools\getdate.exe is being pulled from SVN even though it
is being generated by getdate.cmd and getdate.c that are both in the same
directory?
-John
Hi,
on the 3rd of May, from 1PM to 6PM CET, the following services will down
due to a power maintenance:
-> ISO upload
-> ISO download
-> Doxygen
-> cppcheck
-> Linux buildbot
-> KVM testbot
-> VMware testbot
I warmly recommend you don't commit during that period then, as
remaining builder, Windows one, won't be able to upload its ISOs.
Actually, I could also take the opportunity of such downtime to take SVN
(svn, git, buildbot master) server down for maintenance as it will
barely harm. I'll keep you informed.
I'll push reminders before it happens.
Sorry for the services interruption.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hello.
I am the guy writing an updater for ReactOS. Recent tests show some
difficulties and errors in data from reactos bootcds; mainly reactos.inf:
My program reads reactos.inf, puts the filepaths together and copies
files to the specified positions in folder-tree (I'm talking about the
server's side). It seems that reactos.inf contains pretty weird data;
opening reactos.inf with gedit shows it intact; reading it with the
program gets the following things out (shortened):
" -- 6 -->cache/files/���"
should be "cache/files/inf" (with cache/files" beeing the path of all
cached files, unpacked from bootcd-ISO.
and (in the same context):
"
-- 5 = system32\drivers\etc
-- 6 = inf
-- 7 = bin
-- �Í = bin\data
-- 9 = media
-- 10 = Microsoft.NET
"
("--" comes from debug-function of my iniparser).
Is this intended to be as is or not? Could someone please fix that or
let me know whether I should think about doing something differently.
I'm working and testing with Xubuntu 13.04 amd64 - always getting latest
dbg-BootCD-ISO.
Thanks peope.
Regards Stefan Naumann
I'm not a fan of single line conditional statements.
I'd prefer if we had a style rule for that.
Any thoughts on that?
Am 01.05.2013 19:12, schrieb hbelusca(a)svn.reactos.org:
> Author: hbelusca
> Date: Wed May 1 17:12:56 2013
> New Revision: 58902
> do
> {
> - while (*LoadOptions == '/')
> - ++LoadOptions;
> -
> + while (*LoadOptions == '/') ++LoadOptions;
> *NewLoadOptions++ = *LoadOptions;
> } while (*LoadOptions++);
>
>
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 25th of April, 19:00 UTC.
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords will
be emailed to you shortly before the meeting starts, and they are going
to be different once again as they are not stored in any database.
Hopefully it's not much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to my email as usual).
Regards,
Aleksey Bragin
Fantastic work Hermes!
Congrats
On 15/04/2013 20:32, "hbelusca(a)svn.reactos.org" <hbelusca(a)svn.reactos.org>
wrote:
>Author: hbelusca
>Date: Mon Apr 15 19:32:00 2013
>New Revision: 58770
>
>URL: http://svn.reactos.org/svn/reactos?rev=58770&view=rev
>Log:
>[REACTOS]
>
>Merge of the ros-csrss branch created with a three-fold purpose:
>
>- Use the new Windows-compatible Client-Server Runtime Subsystem (csrss +
>csrsrv)
>written by Alex Ionescu to replace the old hacked one. Also the CSR
>client part,
>residing in ntdll, is updated. Some work also done on the dlls side, which
>communicate with CSR, namely kernel32.
>
>- Replace our very old win32csr.dll CSR server by the collection
>basesrv.dll /
>winsrv.dll as it is done under Windows.
>
>- Since the console subsystem is (for historical purposes on Windows) the
>only subsystem which exploits all the possibilities of the CSR, I decided
>to
>put it in a new CSR dll called 'consrv.dll', even if on Windows it is
>included
>together with other APIs inside the winsrv dll (since Windows NT 3.1
>release)
>(I took the name 'consrv' from the dll where it was included in Windows
>NT 3.1
>beta from October 1991). Some work was also done on its internal
>architecture
>(the external interface is of course unchanged for compatibility reasons)
>and a
>two-layer approach was developed, using the existing idea of console
>functions +
>GUI or TUI we already had in win32csr:
> * the "console server" which dialogs with the console applications,
>and which maintains a list of all the created consoles.
> * different "front-ends" corresponding to where you want to output
>the information (~= console hardware) (Work-In-Progress).
>Another idea would be to make those front-ends dynamically-loadable
>(instead
>of being compiled inside consrv).
>- I also fixed some parts of the console properties dialog box.
>
>More information can be found in
>http://www.reactos.org/archives/public/ros-dev/2013-April/016121.html
>
>CORE-122 CORE-2510 CORE-7002 #resolve #comment Committed in revision
>r58xxx.
Hello everybody,
This message is to remind you that the merge will happen on Monday 15. (of
this month) in the evening (~= 19 or 20:00 UTC).
Hermès
-----Message d'origine-----
De : Hermès BÉLUSCA - MAÏTO [mailto:hermes.belusca@sfr.fr]
Envoyé : mardi 9 avril 2013 12:48
À : 'ReactOS Development List'
Objet : Future merge of the ros-csrss branch into the trunk
Hi all !
I'm writing this mail to announce to you that in one week (if everything
works as expected till this time) I will be ready to merge my ros-csrss
branch into our current codebase.
[...]
Hi guys,
the KVM testbot has been upgraded from 0.12.3 to 1.0. This means that
you could find new regressions. On testman, the starting revision at
which it has been used is: 58727.
It's interesting to note that previously the KVM testbot was running
headless (no VNC display on ReactOS VM). With newer release, this is
impossible. Either ReactOS or KVM locks up because of this. See:
http://build.reactos.org/builders/Linux_AMD64_1%20KVM-Test/builds/2710/step…
With my best regards,
--
Pierre Schweitzer<pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hi all !
I'm writing this mail to announce to you that in one week (if everything
works as expected till this time) I will be ready to merge my ros-csrss
branch into our current codebase.
The ros-csrss branch
(http://svn.reactos.org/svn/reactos/branches/ros-csrss/?view=log) was
started 5 months ago (October 14, 2012 to be precise) with a three-fold
purpose:
- Use the new Windows-compatible Client-Server Runtime Subsystem (csrss +
csrsrv) written by Alex Ionescu, unused at the moment and which currently
lives in trunk/reactos/subsystems/csr/, and as such was a replacement for
the older one in trunk/reactos/subsystems/win32/csrss/. This last one was
progressively hacked to include functionalities from the new csrss; however
most of the old code remained and as such it was a big hack. Also the CSR
client part, residing in ntdll, was updated (thanks to comments put by Alex
inside it). To communicate between the server-part and the client-part, some
messaging protocol is used (thanks to LPC); the used structures were not so
up-to-date, but the new ones were in the code, not used. So I could use them
instead of the older ones. That meant that some work was needed in ntdll (as
previously stated). Disregarding the details (you can see them in the commit
log), I also had to rework a little bit on the dlls which communicate with
CSR, namely kernel32.
- Replacing our very old win32csr.dll csr server by the collection basesrv /
winsrv as it is done under Windows. For that I tried to match accurately our
existing code with what should exist on Windows according to this list of
CSR servers APIs : http://j00ru.vexillium.org/csrss_list/api_list.html .
- Since the console subsystem is (for historical purposes on Windows) the
only subsystem which exploits all the possibilities of the CSR, much of the
work in the branch was done to make it working with the new csrss. Even if
on Windows it is included together with other APIs inside the winsrv dll
(since Windows NT 3.1 release), I decided to put it in a separate dll,
called consrv, on ReactOS (I took the name from the dll where it was
included in Windows NT 3.1 beta from October 1991). Also, because I believe
that the console subsystem is something that, on Windows, was somewhat
neglected (no ANSI control, (almost?)no TTY-like flavour...) I decided to
work on its internal architecture (the exterior one being unchanged for
compatibility reasons) such as to exacerbate the following things:
* the "console server" which dialogs with the console applications,
and which maintains a list of all the created consoles.
* different "front-ends" corresponding to where you want to output
the information (~= console hardware) (it is of course work-in-progress). At
the moment only one is working: the GUI console. I have to make the TUI
interfacing correctly with the rest of the code (but since it's not used for
now, it's not extremely urgent). The idea would be to have also a front-end
for serial ports, so that we could interact with the serial port (with Putty
if running ROS on a virtual machine, or with a serial console, etc...). And
another idea would be to make those front-ends dynamically-loadable (instead
of being compiled inside consrv).
- I also fixed some parts of the console properties dialog box.
Here is the JIRA report for the merge:
http://jira.reactos.org/browse/CORE-7002
Here are the test results with revision 58723 (plus comparison with
revisions 58722 and 58720):
http://old.reactos.org/testman/compare.php?ids=16213,16218,16219,16221
You will see that the ntdll:exception seems to run 24 more tests, but 4
failed compared to non-patched r58723. The errors are "exception.c:821: Test
failed: Eip at 0x77f2b2a3 instead of 0079000B". It would be interesting to
investigate further on these failings.
Also, gdi32:font executes 33 more tests, and 10 more fail, due to the
Fixedsys font.
A problem, already existing in trunk, remains:
http://jira.reactos.org/browse/CORE-6397 (see description inside).
You are encouraged to make comments, etc... etc...
Cheers,
Hermès.
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=
~=~=
Documentation I've used :
=========================
- The oldest trace of CSRSS in NT 3.1 beta (where I've found the existence
of csrsrv.dll, which was merged with winsrv.dll in the 3.1 release and the
subsequent versions of NT): http://www.logotypes.se/NT310CSRSS.txt
- "Windows CSRSS cross-version API Table" http://j00ru.vexillium.org/?p=349
and the subsequent links.
- "Windows CSRSS Write Up: the basics (part 1/1)"
http://j00ru.vexillium.org/?p=492
- "Windows CSRSS Write Up: Inter-process Communication (part 1/3)"
http://j00ru.vexillium.org/?p=502
- "Windows CSRSS Write Up: Inter-process Communication (part 2/3)"
http://j00ru.vexillium.org/?p=527 (the messaging system CSR server <-->
client is explained here)
(the part 3/3 seems to not exist)
- "CVE-2011-1281: A story of a Windows CSRSS Privilege Escalation
vulnerability" http://j00ru.vexillium.org/?p=893 and
http://mysterie.fr/blog/2011/07/31/cve-2011-1281-privilege-escalation-in-csr
ss-proof-of-concept/
- Something that would be interesting for console and thread desktops :
"Defeating Windows Driver Signature Enforcement #2: CSRSS and thread
desktops" http://j00ru.vexillium.org/?p=1393
- " Windows Subsytem Csrss" (in French)
http://www.ivanlef0u.tuxfamily.org/?p=188
- "Story of a dumb patch", Cesar Cerrudo,
http://www.argeniss.com/research/MSBugPaper.pdf or
http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf
- CsrWalker :
http://forum.sysinternals.com/csrwalker-processes-detection-from-user-mode_t
opic15457.html
- Concerning console modes flags:
https://sites.google.com/site/marckupper/utilities/setconsolemode
- Documentation about consoles on MSDN:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682010(v=vs.85).as
px
- "Custom console hosts on Windows 7 (Hack in the Box Magazine #4)"
http://magazine.hitb.org/issues/HITB-Ezine-Issue-004.pdf
- "Windows CSRSS Tips & Tricks (Hack in the Box Magazine #5)"
http://magazine.hitb.org/issues/HITB-Ezine-Issue-005.pdf
- "Win32 Console (Wikipedia)" and the note 3 of the article:
http://en.wikipedia.org/wiki/Win32_console#cite_note-3
- Undocumented flags of ConsoleProcess:
http://www.catch22.net/tuts/undocumented-createprocess
-------- Original Message --------
Subject: [ReactOS] Your organization application has been rejected.
Date: Mon, 08 Apr 2013 18:43:14 +0000
From: no-reply(a)google-melange.appspotmail.com
To: amine.khaldi(a)reactos.org
Thank you for submitting "ReactOS" organization application to Google
Summer of Code 2013. Unfortunately, we were unable to accept your
organization's application at this time. Every year we receive many more
applications than we are able to accommodate, and we would encourage you
to reapply for future instances of the program.
If you would like some general feedback on why your organization was not
accepted, please consider attending the IRC meeting in #gsoc on Freenode
on Friday, April 19, 2013 at 16:00 UTC.
Best regards,
Google Open Source Programs
Hi,
due to hardware issues, the Linux builder is currently offline.
Can't provide any ETA for recovery yet.
Sorry for the troubles.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hi guyz!
I've been reviewing our current Blacklisted suites at Testman. A lot of those unstable testsuites now are reliable, maybe because ReactOS stability has increased or better Winetests.
The following blacklisted suites in the past should go into whitelist:
Gdi32:SetMapMode. Now scores: 51-0
Gdi32:SetSysColors. Now scores: 44-0
Gdiplus:graphicspath. Now scores: 434-32
Gdiplus:region. Now scores: 803-6
Kernel32:pipe. Now scores: 33895-124
user32:trackmouseevent. Now scores: 177-12
wininet:urlcache. Now scores: 186-16
The following suites look reliable but from time to time they score different.So they should be kept as Blacklisted:
user32:msg
user32:win
In the other hand two new candidates should go into Blacklisted:
msxml3:domdoc
ntdll:info
Not bad, 7 to whitelist, 2 almost reliable and just 2 into Blacklist.
My proposal is to update the lists and check during the following days that these new changes are reliable.
If testsuites are a sign of stability, I should say..ReactOS is really stable. Bugged as always.But stable. :)
Hi,
Here is a patch for the missing WM_NCRBUTTONUP. It's wine code. Well
it breaks the mouse pointer set position and activates the system menu
at the left upper corner. Looks like to many hack being made to bypass
unimplemented functions. So stop doing it and fix it. I know~ locating
all of them is a big head ache but remember what I always type, don't
build code on top of hacks on hacks!
James
Index: win32ss/user/user32/windows/defwnd.c
===================================================================
--- win32ss/user/user32/windows/defwnd.c (revision 58633)
+++ win32ss/user/user32/windows/defwnd.c (working copy)
@@ -22,6 +22,7 @@
LRESULT DefWndNCHitTest(HWND hWnd, POINT Point);
LRESULT DefWndNCLButtonDown(HWND hWnd, WPARAM wParam, LPARAM lParam);
LRESULT DefWndNCLButtonDblClk(HWND hWnd, WPARAM wParam, LPARAM lParam);
+LRESULT NC_HandleNCRButtonDown( HWND hwnd, WPARAM wParam, LPARAM lParam );
void FASTCALL MenuInitSysMenuPopup(HMENU Menu, DWORD Style, DWORD
ClsStyle, LONG HitTest );
void MENU_EndMenu( HWND );
@@ -1101,14 +1102,7 @@
}
case WM_NCRBUTTONDOWN:
- {
- /* in Windows, capture is taken when right-clicking on
the caption bar */
- if (wParam == HTCAPTION)
- {
- SetCapture(hWnd);
- }
- break;
- }
+ return NC_HandleNCRButtonDown( hWnd, wParam, lParam );
case WM_RBUTTONUP:
{
Index: win32ss/user/user32/windows/nonclient.c
===================================================================
--- win32ss/user/user32/windows/nonclient.c (revision 58633)
+++ win32ss/user/user32/windows/nonclient.c (working copy)
@@ -1035,6 +1035,14 @@
case HTBOTTOMLEFT:
case HTBOTTOMRIGHT:
{
+ /* Old comment:
+ * "make sure hittest fits into 0xf and doesn't overlap
with HTSYSMENU"
+ * This was previously done by setting wParam=SC_SIZE + wParam - 2
+ */
+ /* But that is not what WinNT does. Instead it sends this. This
+ * is easy to differentiate from HTSYSMENU, because HTSYSMENU adds
+ * SC_MOUSEMENU into wParam.
+ */
SendMessageW(hWnd, WM_SYSCOMMAND, SC_SIZE + wParam -
(HTLEFT - WMSZ_LEFT), lParam);
break;
}
@@ -1073,6 +1081,41 @@
return(0);
}
+/***********************************************************************
+ * NC_HandleNCRButtonDown
+ *
+ * Handle a WM_NCRBUTTONDOWN message. Called from DefWindowProc().
+ */
+LRESULT NC_HandleNCRButtonDown( HWND hwnd, WPARAM wParam, LPARAM lParam )
+{
+ MSG msg;
+ INT hittest = wParam;
+
+ switch (hittest)
+ {
+ case HTCAPTION:
+ case HTSYSMENU:
+ if (!GetSystemMenu( hwnd, FALSE )) break;
+
+ SetCapture( hwnd );
+ for (;;)
+ {
+ if (!GetMessageW( &msg, 0, WM_MOUSEFIRST, WM_MOUSELAST )) break;
+ if (CallMsgFilterW( &msg, MSGF_MAX )) continue;
+ if (msg.message == WM_RBUTTONUP)
+ {
+ hittest = DefWndNCHitTest( hwnd, msg.pt );
+ break;
+ }
+ }
+ ReleaseCapture();
+ if (hittest == HTCAPTION || hittest == HTSYSMENU)
+ SendMessageW( hwnd, WM_SYSCOMMAND, SC_MOUSEMENU + HTSYSMENU,
msg.lParam );
+ break;
+ }
+ return 0;
+}
+
VOID
DefWndTrackScrollBar(HWND hWnd, WPARAM wParam, POINT Point)
{
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 28th of March, 19:00 UTC. And that's tomorrow!
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords will
be emailed to you shortly before the meeting starts, and they are going
to be different once again as they are not stored in any database.
Hopefully it's not much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to my email as usual).
Regards ,
Aleksey Bragin
---------- Forwarded message ----------
From: Zachary Gorden <drakekaizer666(a)gmail.com>
Date: Thu, Mar 28, 2013 at 9:47 AM
Subject: Do NOT attempt to translate Book pages
To: ReactOS General List <ros-general(a)reactos.org>, ReactOS Web List <
ros-web(a)reactos.org>
The development guide is using Drupal "Books" as a way of organizing
content. Drupal's localization has a major hole wherein books cannot be
translated. As such, do NOT attempt to translate the development guide or
any other content that uses books.
Hi,
due to a maintenance on the server running them, the following services,
Jira & Fisheye, will be down on the 20th of March 2013, starting at 9h30
CET. This means that the URLs: http://jira.reactos.org &
http://code.reactos.org will be unreachable during the meantime.
The server (and its services) should be back online before midday.
We are sorry for the caused inconvenience.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hello everybody !
About two or three weeks ago I translated in French the "ReactOS Downloads"
page of our new website, and I was very surprised (and very angry, too)
yesterday to see that it was turned back into English. According to the
history it was done 4 days ago. Do you know what happened there, and how can
this be reverted, if possible ?
Thanks in advance,
Hermès BÉLUSCA - MAÏTO
Hey,
Amine informed me about yet another case of Vista APIs being used in
wine code. This problem is going to increase and we need a solution, the
sooner the better.
My plan to address this is to use lower layer DLLs that contain the
actual implementations, while the upper layer DLLs (kernel32, advapi32,
msvcrt*) are just forwarders to the lower layer DLLs. The lower layer
DLLs can contain whatever we want and wine dlls can link to them, while
applications continue to see version consistent exports of the standard
winapi dlls.
For the exports of kernel32 and advapi32, a possible way to organize
this is to follow MS API reorganisation on Win7, where these APIs are
separated into the API-MS-Win-core-* etc dlls. In fact on Windows the
implementation still stays in either Kernel32 or kernelbase and the
API-MS-* dlls are just "virtual" dlls. How these APIs are organized can
be seen here:
http://www.nirsoft.net/articles/windows_7_kernel_architecture_changes.html
While from a logical perspective it might make sense to organize our
implementations physically into these API DLLs, it comes with an
overhead, since a bunch of extra dlls would need to be loaded and
initialized on every process creation.
We can avoid that by organizing our code in static libraries and merge
them all together to 2 core dlls.
The division like on Windows 7: kernelbase + kernel32 + advapi32,
doesn't work for us, since kernel32 and advapi32 would still need to
contain Vista+ APIs.
Therefore I suggest to divide it into kernelbase.dll and kernelsup.dll,
the latter containing the code that remains in kernel32 and advapi32 on
Windows.
Additional advantage:
For the various CRT modules this can be done as well and would provide
the benefit of having a single full featured CRT, which we can use from
our own code, while still providing a (limited) version specific MSVCRT.
And all other MSVCR* can forward to that core DLL, so we only need to
load CRT code once.
We would have another benefit, when we decide to implement
Windows-Version specific API layers. These can be implemented as
different versions of kernel32.dll etc. which export whatever they do on
a specific Windows Version and contain version specific hacks, if
required. These Version specific DLLs would be placed into subfolders on
system32, having the loader use them, whenever a link/pif/registry
setting asks for a specific (non-default) version.
If someone has doubts and fears this could cause compatibility issues:
Yes it could, but those only apply to extremely special system tools,
which wouldn't work on Windows 7 either.
Since we simply cannot be 100% compatible (unless we copy the MS
binaries and call them ours), we need to make a compromise at certain
points. We really have other problems than some crazy XP/2003 only
system tools not working. The benefits far outweight the problems.
Otherwise MS would never have fiddled with their DLLs.
If someone prefers a different system of organization, I'd be happy to
hear about it.
If there are no objections, I will create a branch and work on that
together with Amine.
Thanks,
Timo
Fix from r58530 deployed on release build slave. Next build will use it.
On 17/03/2013 00:31, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/384
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_1B
>
> Build Reason: The web-page 'force build' button was pressed by 'spetreolle':
>
> Build Source Stamp: 58530
> Blamelist:
>
> BUILD FAILED: failed compile_3
>
> sincerely,
> -The Buildbot
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hi,
Just for the record, release build is broken.
With my best regards,
On 16/03/2013 13:52, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/383
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_1B
>
> Build Reason: The Periodic scheduler named 'release' triggered this build
> Build Source Stamp: HEAD
> Blamelist:
>
> BUILD FAILED: failed compile_3
>
> sincerely,
> -The Buildbot
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
I get an error 500 when attempting to use the result diff mechanism see
http://reactos.org/sites/all/modules/reactos/testman/diff.php?id1=4131230&i…
example
This is an excellent utility in testman, please don't take it away.
I would also like to take this oportunity to thank everyone involved in the
hard work of keeping ReactOS and related services alive, functioning
properly and implementing new features!
Great work on those, Hermes!
Regards,
Alex Bragin
On 14.03.2013 5:14, hbelusca(a)svn.reactos.org wrote:
> Author: hbelusca
> Date: Thu Mar 14 01:14:18 2013
> New Revision: 58493
>
Hey there,
I'm doing an updater for ReactOS and I need code, that can download
files from a server - like a webserver. Something like wget under Linux.
I don't have the knowledge yet, to implement this on my own, so I used
for the updater-Server wget under Linux and wanted to ask you, whether
someone of you can help me here and write nice code, that is well
explained in comments, so I can learn from it and the updater gets finished.
Thank you very much.
Regards Stefan Naumann
Hi,
in order to perform an important maintenance on the development server,
it will be down on Wed 6th March, starting in the morning (approx 9h30
CET). It means that during this period: git, svn, buildbot won't be
available to anyone.
We are sorry for the caused consequences.
With my best regards,
--
Pierre Schweitzer<pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hello,
How can I translate the CMS to Italian, and have support for Italian language on the “Translate” tab of the news?
Riccardo Bestetti
Da: Zachary Gorden
Data invio: 3-mar-13 04.04
A: ReactOS General List, ReactOS Web List, ReactOS Development List
Oggetto: [ros-dev] Website translation guide
Due to Aleksey's nagging, I've put together a translation guide here:
http://www.reactos.org/website-translation
Now that the guide has been effectively formalized, anyone that
manages to break the English site due to not following the
instructions will lose their translation access until they can provide
a written explanation of how to do the translation correctly, in their
own words.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Hi all,
Google will host its Summer of Code again this year. Let's try to get in
again after our successful participation in 2011!
Who's available to write up a new idea page along with the student
guide? Let's draft it in a Google doc again.
I believe that some more ideas can be added, i.e. tasks on Explorer-New
now that work has progressed on it. Others need to be removed, such as
the finished AHCI support for UniATA or my KD USB-to-Serial driver,
which nobody really understood ;)
Deadline is 18th March, so about 2 weeks to go.
References:
* http://reactos.org/wiki/Google_Summer_of_Code_2012
* http://reactos.org/wiki/Google_Summer_of_Code_2012_Ideas
- Colin
Due to Aleksey's nagging, I've put together a translation guide here:
http://www.reactos.org/website-translation
Now that the guide has been effectively formalized, anyone that
manages to break the English site due to not following the
instructions will lose their translation access until they can provide
a written explanation of how to do the translation correctly, in their
own words.
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 28th of February, 19:00 UTC, which
coincidentally is the last day of this month too.
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords will
be emailed to you shortly before the meeting starts, and they are going
to be different once again as they are not stored in any database.
Hopefully it's not much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to my email as usual). There are no hot topics
scheduled yet, so you're free to help ;)
With the best regards,
Aleksey Bragin
Hi,
the server appears to have died in live (likely a disk issue - thanks
Munin!).
We'll fix and bring it up ASAP.
Sorry about that.
With my best regards,
On 02/27/2013 03:11 PM, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Linux_AMD64_1 KVM-Test while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Linux_AMD64_1%20KVM-Test/builds/2416
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_1
>
> Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger)
> Build Source Stamp: 58374
> Blamelist: tkreuzer
>
> BUILD FAILED: failed test
>
> sincerely,
> -The Buildbot
>
>
--
Pierre Schweitzer<pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hi,
some services are experiencing an unexpected downtime (Jira, Web,
Fisheye, DNS). We are currently working on it.
Sorry for the inconvenience.
With my best regards,
--
Pierre Schweitzer<pierre(a)reactos.org>
System Administrator
ReactOS Foundation
The issue is now fixed. This is linked to site migration.
Sorry for the inconvenience.
On 18/02/2013 21:33, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/251
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_2
>
> Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger)
> Build Source Stamp: 58341
> Blamelist: tkreuzer
>
> BUILD FAILED: failed shell
>
> sincerely,
> -The Buildbot
>
>
Hi,
we are currently facing some issues with mails delivery on
www.reactos.org website. This means that any mail cannot be delivered at
the moment. We are working on the issue.
The other sites (jira for instance) are not affected by this issue.
With my best regards,
--
Pierre Schweitzer<pierre(a)reactos.org>
System Administrator
ReactOS Foundation
RMS?
Hang-out from time to time near 77 Mass Ave.? J
-John
I actually did get a simple port of freeloader and reactos working on my
iPod touch a while ago. :P
On Dec 25, 2012, at 4:55 AM, Hermès BÉLUSCA - MAÏTO <hermes.belusca(a)sfr.fr>
wrote:
Well, I fear Igor is right.
Hermès.
De : <mailto:ros-dev-bounces@reactos.org> ros-dev-bounces(a)reactos.org [
<mailto:ros-dev-bounces@reactos.org> mailto:ros-dev-bounces@reactos.org] De
la part de Igor Paliychuk
Envoyé : mardi 25 décembre 2012 07:16
À : ReactOS Development List
Objet : Re: [ros-dev] Status of ARM Development
If you want to help, go ahead. If you are just asking, the answer is: "There
is no work on ARM port going on because there are no human resources for
doing that". Well, at least afaik.
2012/12/25 J. C. Jones <jaibuduvin(a)gmail.com>
Hi All,
Newbie here (2 days). I would like to know the who-is-doing-what for the ARM
port. It seems that, with the current lock-down of all three major mobile
platforms (iOS/Android/Windows Phone 8), as well as the impending surge in
2013 of ultra-cheap mobile devices like tablets based on ARM, and of course,
the loveable Raspberry Pi, a truly open Windows-oriented platform is more
needed than ever.
J.C.
_______________________________________________
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
_____
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/5987 - Release Date: 12/25/12
Is there any documentation available for where ReactOS stores its
logfiles? For a phase 2/3 installation to harddisk, obviously it gets
stores on drive C: somewhere. For phase 1, screen and debugport
(com/rs232) seem to be the only options. Same goes for the BootCD and
LiveCD.
As I'm experiencing massive issues with getting ReactOS to boot on
USB-enabled real-hardware systems, I'd like to boot from the CD and have
ReactOS automatically write logfile to whichever first FAT filesystem it
can find. Irrelevant if it's USB stick or ATA hdd-partition. Is this
possible or even already done?
If above is not possible, which exact configuration settings would I
need for Bochs or QEMU (so I get debug log file) to add:
* USB optical device (ISO file on host)
* USB harddisk (hdd-imagefile on host)
* USB mouse
* USB keyboard
Lacking a 2nd system and photocamera device, all that remains for
obtaining logfiles is using an emulator, which usually configure their
hdd/cd as ATAPI devices and input as PS/2 devices
I'm hoping an emulator will show same issues as on real hardware, and
that the logfiles can add to bugreports already present.
Bernd
PS: tested 58013 and searched
http://jira.reactos.org/secure/IssueNavigator.jspa for USB
PPS: Haiku happily boots up on this machine from my isostick device.
Hi All,
I install the RosBE on my machine(gentoo linux + kde )
when I successfully ran the RosBE-Builder.sh, and
then the createshortcut.sh to create a short cut on desktop,
it failed.
It is cause by that createshortcut.sh assume that here exist
a $HOME/Desktop, but I haven't a desktop folder in $HOME
At the very top of script[RosBE-Unix-2.1/scripts/createshortcut.sh]
there is :
----- snippt -----
# Constants
DEFAULT_SHORTCUT_DIR="$HOME/Desktop"
----- snippt -----
It makes an ill-conceived assumption, because :
1) No Desktop folder must be guaranteed, though KDE/GNOME
provides it by default, but when I install it by my own, it doesn't.
2) Even it exsits ,the name of the Desktop folder is locale-specified,
for example, it may be in chinese word form.
So a portable, robust way is :
* Probe the folder use a tool called * xdg-user-dir, *provided
the freedesktop.org, which is shipped with most
distro compliant with
freedesktop.org.(xdg-user-dirs<http://freedesktop.org/wiki/Software/xdg-user-dirs>)
* If there isn't this tool or it fails to probe
the folder, we shall check the $HOME/Desktop explictly; if it fails
again, we should create it
manually.
Here is my fix:
XDG_USER_DIR_BIN=`which xdg-user-dir` && \
DEFAULT_SHORTCUT_DIR=`$XDG_USER_DIR_BIN DESKTOP`
if test -z ${DEFAULT_SHORTCUT_DIR} ; then
[ -d $HOME/Desktop ] && DEFAULT_SHORTCUT_DIR=$HOME/Desktop
else
mkdir $HOME/Desktop && DEFAULT_SHORTCUT_DIR=$HOME/Desktop
Hello,
Let me invite you to the combined monthly status meeting taking place
last Thursday of this month, 31st of January, 19:00 UTC.
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Colin says. Pierre would be unable to help,
unfortunately. If Colin is not available, then the meeting would take
place on the Freenode server in a special channel.
Note that the IRC service will only be started shortly before the
meeting. Your participation passwords will be emailed to you shortly
before the meeting starts, and they are going to be different once again
as they are not stored in any database. Hopefully it's not much of
inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to my email as usual). Hot topics would include 2012
fundraising results, switching over to the new website, contracts
progress, and other stuff.
With the best regards,
Aleksey Bragin
Hi,
I switched ReactOS Wiki to readonly state, to be able to export and
transfer data to the new MediaWiki.
Thanks for your patience!
Regards,
Aleksey Bragin
im sure you have already talked about this, but let me ask....
have you thought about including some kind of "apport" application into
ReactOS? this would allow users to automatically send bug reports when
executing a non-running app, way more precise than manually reporting....
what do you think about this?
Hi All,
Before I reach the point where I am thinking the same way as everyone else,
which will inevitably happen (The Borg - resistance is futile), I wanted to
get some thoughts out:
A question that many have asked is, "Why not port ReactOS to ARM?"
The answer is usually something like, "We cannot afford the resources to
port to ARM."
I think on the contrary, the opposite might be true:
1. There is a hoard of developers over on the Raspberry Pi site right
now who would enjoy seeing ReactOS on the RaspPi.
2. There are device manufacturers who would like to free themselves
from the Apple/Google/Microsoft triumvirate and iOS/Android/Windows Phone 8
lock-in. Samsung recently announced its intent to explore other operating
systems.
http://news.cnet.com/8301-1035_3-57455054-94/would-samsung-ever-leave-androi
d-new-ceo-drops-hints/
3. The operating systems are not exactly easy to develop for. I have
read credible articles that Android is a mess from a development
perspective. ReactOS would be the operating system of choice for
straightforward development.
4. There are embedded systems companies who struggled in vain to get
Windows CE to behave like "Big Windows", but were unsuccessful because
restrictions in the Windows CE kernel. Many of them switch to Linux, but
quite a few still use some form of embedded Windows, and would welcome an
open-source Windows-like OS.
5. The United States Military has very large base of software that
they would like to put on lower-power systems (ARM) that is written for
Windows/i386. They are currently trying to port this software to Linux, with
varying degrees of success, not because they like Linux, but because they
need as much of the software to be open as possible. They would be
particularly attracted by the open-source nature of ReactOS, because the USA
national security vetting process requires that certain classes of software
be reviewed, line by line, by a certain US security agency. The singular,
totally exposed nature of ReactOS makes it attractive in this regard.
6. ReactOS.ORG would likely receive real money from device
manufacturers. Even a few dollars per-device would add-up very quickly.
7. There is NO mobile platform right now, among the Big Three, that
allows true, native, C/C++ development. Each of these platform plays a game
where the native code is invoked by some shell, even in the case of Windows
Phone 8, despite Microsoft's claim that Windows Phone 8 supports native
development. [It depends on what your interpretation of native development
is.]
ARM device manufacturers are all stuck in the same boat. Most of these
companies are actually not very good at OS design. Think about it: Nokia was
a multi-billion-$US company that was using an operating system (Symbian)
that was so broken and toxic to innovation that it almost drowned their
company. What did they do to fix this problem? They adopted a closed OS from
Microsoft. Manufacturers, actually, do not like having closed software. It
eliminates their opportunity for differentiation. If ReactOS were made to
run on a single manufacturer's device, the other manufacturers would become
nervous, and insist on having the same access as does their competitor.
There is nothing wrong with making these manufacturers pay a small fee to
support the ReactOS Foundation, and they would gladly pay it, if we
developed killer applications for their devices.
Of course, because most of ReactOS, in theory, should be portable, software
working on ARM is software working on x86_32/x86_64. I would also like to
mention here that there are a lot of developers who would much rather have a
stable kernel, and a paucity of user-mode applications, versus an unstable
kernel, and a plethora of user-mode applications. User mode applications
will be created by the hoard, *if* the kernel is stable. If the kernel is
not stable, the incentive to do anything else is greatly reduced.
This is the opportunity I see. My biological clock is telling me that 2013
is the year to pursue this effort. The market is waiting. But an effort like
porting to ARM should not be done haphazardly or opportunistically. It
should be done with deliberation and intent.
Just my opinion.
-John
Hi,
I had forgotten all about BOCHS. It is amazing how many emulators there are on the market these days.
I think that, for mass appeal, we should try to get ReactOS to run natively. The problem is that there are basically two types of users of ReactOS:
1. Those who enjoy OS development.
2. Those who do not enjoy OS development. :)
#1 is the type that might run ReactOS inside an emulator.
#2 is the type that would probably never run ReactOS inside an emulator, even if ReactOS were stable.
Unfortunately, for all the people who might run ReactOS someday [millions and millions of people] the ratio #1/#2 is probably less than 1/100, conservatively speaking.
Therefore, it makes sense to get ReactOS to run on as many of the devices that users of type #2 would use. That leads to the following reasoning:
There are several popular CPU's on the market. X86_32/x86_64 rules the desktop. ARM is 90% of mobile devices. And there is the "other" category, which is less than 10% of all new devices, including mobile.
Since it is not (yet) likely that a user of type #2 will remove Microsoft Windows from an existing device and replace it with ReactOS, even if ReactOS were stable, one must conclude that the best way to get ReactOS onto as many devices as possible is to make ReactOS the first OS on the device before any other OS has a chance to be on the device. That means new devices.
New devices come with Microsoft Windows, iOS, or Android. Getting HP, Dell, ASUS, Acer, etc..to start using ReactOS instead of Microsoft Windows on their hardware is an up-hill battle and not likely to succeed. Apple hardware, of course, is out of the question. That leaves Android hardware, which is more vulnerable, IMO, than people might think. Google does not own these devices. As Timo showed, there are manufacturers in China/Taiwan/Korea, etc. that make Android hardware very cheaply. Those manufacturers choose Android, but they could choose whatever they desire.
So I think that getting ReactOS to run on just one, commonly-available, mobile device, like an ARM-based SmartPhone, that is made by a hardware manufacturer who is not committed to Android or any other OS, would open the flood-gates.
I would not worry about the number of available "apps" on ReactOS on ARM, because there are many, many developers who know how to write applications for Microsoft Windows on x86_32/x86_64, and therefore, for ReactOS on ARM, and they will be immediately attracted by the open nature of ReactOS. Also, I suspect that the following technique for converting Windows-on-x86_32 applications to ReactOS-on-ARM will work:
http://www.reactos.org/forum/viewtopic.php?f=9&t=12262
Cheers!
-John
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of HeChi-Lau
Sent: Saturday, January 19, 2013 10:20 AM
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Ros-dev Digest, Vol 101, Issue 30
Hey,Do you know the BOCHS?An x86 emulator.Its android version works fine through the JNI library.Reactos also runs okay.But I configured the net card in conf file,nothing effected.
In my opinion if anyone could develop a similar,but advanced software:it included full hardward support and released with reactos.Or just add the x86 vm or in reactos's kernel,and then reactos can work with arm cpus.After one of I said above done,I believe more people will know reactos and use it.
reactos has some advantages that other os can't compared with.such as free,fully opensource,pe compatible,low memory usage and fast boot and shutdown.If application experience be better,it will be finer.
Hey,Do you know the BOCHS?An x86 emulator.Its android version works fine through the JNI library.Reactos also runs okay.But I configured the net card in conf file,nothing effected.
In my opinion if anyone could develop a similar,but advanced software:it included full hardward support and released with reactos.Or just add the x86 vm or in reactos's kernel,and then reactos can work with arm cpus.After one of I said above done,I believe more people will know reactos and use it.
reactos has some advantages that other os can't compared with.such as free,fully opensource,pe compatible,low memory usage and fast boot and shutdown.If application experience be better,it will be finer.
ros-dev-request(a)reactos.org wrote:
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: Status of ARM Development (J. C. Jones)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Jan 2013 19:23:50 -0600
From: "J. C. Jones" <jaibuduvin(a)gmail.com>
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] Status of ARM Development
Message-ID: <00af01cdf5e3$a37f1b50$ea7d51f0$(a)gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi RMS,
What happen to your port?
-John
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of rms(a)velocitylimitless.org
Sent: Wednesday, December 26, 2012 6:04 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Status of ARM Development
I actually did get a simple port of freeloader and reactos working on my iPod touch a while ago. :P
On Dec 25, 2012, at 4:55 AM, Herm?s B?LUSCA - MA?TO <hermes.belusca(a)sfr.fr> wrote:
Well, I fear Igor is right.
Herm?s.
De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la part de Igor Paliychuk
Envoy? : mardi 25 d?cembre 2012 07:16
? : ReactOS Development List
Objet : Re: [ros-dev] Status of ARM Development
If you want to help, go ahead. If you are just asking, the answer is: "There is no work on ARM port going on because there are no human resources for doing that". Well, at least afaik.
2012/12/25 J. C. Jones <jaibuduvin(a)gmail.com>
Hi All,
Newbie here (2 days). I would like to know the who-is-doing-what for the ARM port. It seems that, with the current lock-down of all three major mobile platforms (iOS/Android/Windows Phone 8), as well as the impending surge in 2013 of ultra-cheap mobile devices like tablets based on ARM, and of course, the loveable Raspberry Pi, a truly open Windows-oriented platform is more needed than ever.
J.C.
_______________________________________________
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
_____
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/5987 - Release Date: 12/25/12
Hi All,
Newbie here (2 days). I would like to know the who-is-doing-what for the ARM
port. It seems that, with the current lock-down of all three major mobile
platforms (iOS/Android/Windows Phone 8), as well as the impending surge in
2013 of ultra-cheap mobile devices like tablets based on ARM, and of course,
the loveable Raspberry Pi, a truly open Windows-oriented platform is more
needed than ever.
J.C.
Hi All,
I had quick chat with Amine and others, and for the time being, I will pick
up where I let off in creating a Visual Studio ReactOS.sln with the
following features:
1. A single ReactOS.sln file that is interchangeable between Visual
Studio 2010 and Visual Studio 2012.
2. A single ReactOS.sln file that incorporates all 800+ .vcxproj files
and allows all 800+ project to be viewable within a single session of Visual
Studio.
3. No (serious) performance problems with load of the ReactOS.sln file
or .vcxproj files.
4. An arrangement in the Solution Workspace that mirrors the structure
of the ReactOS repository on disk.
5. The ability to build all applications or drivers by right-clicking,
within Solution Workspace, on the folder named applications or drivers and
doing clicking Build.
6. Visibility of the lang directories in the Solution Workspace.
7. Visibility of all SVN files in the Solution Workspace, including
CMakeLists.txt files.
8. Support for Debug and Release project configurations.
9. Support for x86_32, x86_64, ARM platform configurations.
10. Self-relative paths for all .h's and .libs's so that solution can be
moved by the developer on his/her local hard disk without consequence.
11. No need to download any extraneous tools. User should be able to type
in SVN URL, either from within Visual Studio, or with Windows Explorer, pull
ReactOS repository, load ReactOS.sln, and start editing/compiling/linking,
debugging.
With the CMakeLists.txt files, the information needed is already present.
With Amine's latest work of actually generating the .vcxproj files, things
become even easier. However, as I have two other moderate projects going
concurrently, one of which I just started, this will take some time. I will
provide updates as I go along.
Cheers,
-John