hi devs,
testing FF3 i have noticed that this app has been slowed down a lot
And there is a high difference between running it with kdbg enabled, and
running without it
Also, log is flooded with the following lines:
(subsystems/win32/win32k/objects/gdiobj.c:814) Attempted to lock object 0x0
of wrong type (Handle: 0x0, requested: 0x40000)
(subsystems/win32/win32k/objects/gdiobj.c:814) Attempted to lock object 0x0
of wrong type (Handle: 0x0, requested: 0x40000)
(subsystems/win32/win32k/objects/region.c:2250) NtGdiCombineRgn requires
hSrc2 != NULL for combine mode 1!
Surely some things really could be split off into separate projects if
people felt the urge without causing any real problems.
This very ftp server, for instance, or a replacement shell (as in a new
explorer.exe). The kind of projects that require more common application
developer skills, rather than reproducing Windows internals.
...alright, so the appropriate shell hooks aren't in place at the moment.
Bad example. Hopefully you kind of get what I'm referring to though.
On May 15, 2009 7:41 PM, "Imre Leber" <imre.leber(a)telenet.be> wrote:
Well that is exactly the reason why linux is broken. Completely useless
unless you pay someone to make a distro.
Please make that kind of crap a thing of the past!
Imre
> > > On Fri, May 15, 2009 at 3:03 AM, Peter Millerchip <
peter.millerchip(a)gmail.com> wrote: >> >> H...
------------------------------
> > _______________________________________________ > Ros-dev mailing list >
Ros-dev(a)reactos.org > ...
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
This should work! It's just writing zero into a place holder in TEB
but it throws a exception and kills boot!
Index: win32k/ntuser/misc.c
===================================================================
--- win32k/ntuser/misc.c (revision 40892)
+++ win32k/ntuser/misc.c (working copy)
@@ -550,6 +550,7 @@
// ci->pClientThreadInfo = &ti->ClientThreadInfo; // FIXME!
ci->pClientThreadInfo = NULL;
ci->ppi = ti->ppi;
+ ci->pDeskInfo = NULL;
}
_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
{
Hi everybody,
Daniel and I just released the new version 1.4.2 of the ReactOS Build
Environment for Windows and Unix.
The most important part of this release is the addition of some environment
variables containing the include directories of the host and target
compilers as compiler flags.
These variables might be required by rbuild in the near future, so the
update to the new version is highly recommended.
Besides, the GCC in RosBE-Windows 1.4.2 is now compiled for i686 or later
CPUs, decreasing the compilation time by 5 minutes for Daniel. Hopefully
another reason to make the update more attractive ;-)
As always, you can get the latest release from
https://sourceforge.net/project/showfiles.php?group_id=6553
Best regards,
Colin
As some of you already know, the ReactOS web team was working on roscms4
for some time. Now it has reached a point where we feel that it is
stable. But before we run it in our production system we want to ensure
that it runs correct, so we're starting a beta test. With this mail we'd
like to invite everyone who has already worked with RosCMS, to do some
testing and helping us to get a stable RosCMS.
You can use your normal login data from www.reactos.org, we're using a
copy from 5. May 2009.
Beta-Test Website: http://backend.reactos.org
Beta-Test RosCMS: http://backend.reactos.org/roscms
please report bugs to http://roscms.dblounge.org/doku.php?id=bugs
Thank you for helping
hpoussin(a)svn.reactos.org schrieb:
> Author: hpoussin
> Date: Mon Apr 27 00:22:16 2009
> New Revision: 40710
>
> [...]
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/arch/amd64/hwacpi.c
>
> Author: hpoussin
> Date: Sat Apr 25 00:35:11 2009
> New Revision: 40686
>
> [...]
>
> Modified:
> trunk/reactos/boot/freeldr/freeldr/arch/amd64/mach.c
> trunk/reactos/boot/freeldr/freeldr/arch/amd64/pcrtc.c
>
Umm, how did you manage to do that? These files don't/shouldn't even exist.
Are you using git? Or voodoo? Black magic haxx0ry? ;)
Timo
Hello devs,
Cameron just asked whether I could configure Bugzilla to automatically add
him to the CC list for "Networking" bugs.
This was done now.
If you want to be automatically on the CC list for a specific bug category
as well, just let me know and I'll add you.
Maybe it's even time to rethink our categories and use more practical ones.
I'm open for constructive ideas in this direction.
Best regards,
Colin
Hi Clemens,
I wonder if you still maintain this code ?
Qemu has recently changed the way to manage network devices,
and I had to do changes to keep it working.
This worked like an charm until today, and is still interesting me as Im beginning tests for wireless nics in ReactOS.
CCing ros-dev mailing list in case someone has it already built it in.
Kind regards,
Sylvain Petreolle
----- Message d'origine ----
> De : Clemens Kolbitsch <clemens.kol(a)gmx.at>
> À : qemu-devel(a)nongnu.org
> Envoyé le : Jeudi, 28 Février 2008, 15h12mn 09s
> Objet : [Qemu-devel] Atheros Wireless Device Emulation
>
> Hi!
> This patch adds virtual wireless networking support to qemu-0.9.1.
> Besides being funny having a wireless LAN in Qemu, I guess wireless driver
> developers could use this a lot.
>
> I have 3 screenshots here:
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_hardware.jpg
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_connecting.jpg
> http://stud4.tuwien.ac.at/~e0126605/qemu_atheros/atheros_wlan_connected.jpg
>
>
> Some infos about the emulation:
> - We simulate an Atheros AR5212 NIC
> - Additionally, we have a virutal access point that can
> be used to connect to Qemu
> - The code is based on ath5k reverse engineering from
> about 10 months ago. I did not check what these guys
> did since then.
> - I added tons of hours doing reverse engineering.. but the
> code is still a MESS! I'm sorry, but at least it works ;-)
> - We can simulate different network card vendors. I.e.
> through an additional model-name, we can specify if the
> network card is identified as "Atheros XXXX" or "HP W400", etc.
> ---> different drivers are installed automatically by guest system
> - The hardware reverse engineering still lacks some stuff. Known
> problems:
> * Depending on the driver, you have to use a different model
> ---> official windows drivers VS. madwifi Linux driver
> * Newest madwifi code probably does not work
> ---> Use Madwifi 0.9.3. Works just fine ;-)
> - The networking-code is still a *little* ugly. Outbound connections
> work, but there seem to be problems for inbound connections (e.g.
> tcp-redirection, etc.)
> - VM Snapshots supported
>
> Some infos about the patch:
> - 2 lines added to pci.c
> - added function declaration to pci.h
> - patched Makefile.target (2 lines)
> - added files qemu/hw/atheros_wlan_.*.[ch]
> - took 2 files from wireshark to generate CRC32 checksums
> - took 3 files from ath5k
> ---> licence people, please have a look if that is ok!!
>
> Enabling emulation:
>
> As I wrote above, there are still problems when using the same code for
> windows and linux guests. The model parameter helps here. Using the NIC on
> windows (that's how I tested):
>
> qemu ... -net user -net nic,model=atheros_wlan_winxp_HPW400 ...
>
> and
>
> qemu ... -net user -net nic,model=atheros_wlan_linux_HPW400 ...
>
> for Linux systems.
>
> The "atheros_wlan" is the device itself, "_linux" / "_windows" is necessary
> because the reverse engineering is still buggy and "_HPW400" gives the NIC
> identification for the guest. HPW400 is the Hewlett-Packard W400 device, but
> there are some more (see the atheros_wlan_eeprom.h for details).
>
> I have used the device on Debian (Kubuntu) Linux. The guests were WinXP-SP2
> and Kubuntu Linux, Kernel 2.6.20, MadWifi 0.9.3. My system is x86, so there
> might be problems with big/little endian I am not aware of!!
>
> Please try the patch and let me know what you think of it!!
>
> Greets,
> Clemens