Hi guys,
I'm reading win32k.sys right now. I found KeyboardThreadMain thread only use
KeyboardClass0 device. I want to know how to communicate
KeyboardClass1,KeyboardClass2, and so on?
Fan Zhang
I've just tried to build the cmake branch for the first time and hit the following error :
-- xmllite has no base address
-- win32csr has no base address
-- Configuring done
CMake Error in dll/ntdll/CMakeLists.txt:
Cannot find source file "ntdll.def". Tried extensions .c .C .c++ .cc .cpp
.cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
Reverting the changes in this revision fixed it.
I know nothing about cmake, but this change appears to have broken the build?
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of jgardou(a)svn.reactos.org
Sent: 01 November 2010 09:32
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [jgardou] 49396: [CMAKE] - put ntdll.def in source files
Author: jgardou
Date: Mon Nov 1 09:32:04 2010
New Revision: 49396
URL: http://svn.reactos.org/svn/reactos?rev=49396&view=rev
Log:
[CMAKE]
- put ntdll.def in source files
Modified:
branches/cmake-bringup/dll/ntdll/CMakeLists.txt
Modified: branches/cmake-bringup/dll/ntdll/CMakeLists.txt
URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/dll/ntdll/CMakeLi…
==============================================================================
--- branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] (original)
+++ branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] Mon Nov 1 09:32:04 2010
@@ -21,10 +21,8 @@
rtl/libsupp.c
rtl/version.c
def/ntdll.rc
- def/ntdll.def)
+ ${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def)
-set_source_files_properties(def/ntdll.def PROPERTIES EXTERNAL_OBJECT TRUE)
-
if(ARCH MATCHES i386)
list(APPEND SOURCE dispatch/i386/dispatch.S)
elseif(ARCH MATCHES amd64)
@@ -48,7 +46,6 @@
endif()
target_link_libraries(ntdll
- ${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def
ntdllsys
libcntpr
pseh)
Hello,
The jgardou changes add thousands of whitespace changes which make it extremely hard to understand what is going on. Please to not arbitrarily change whitespace across 18 files in a patch!
Also, there is nothing wrong with the way ClassPNP was defined before. If you think "How on Earth did this work in trunk?", as quoted from the commit log, maybe you should ask others "Hey, how did this work?".
Please revert the changes and come ask how it worked, I'll be happy to help.
-r
Hi reactos developers.
As many of you know, the cmake branch development is going along and is
the occasion of many innovations in the way reactos is built.
One of this way is the reactos.dff file. Currently, it is a static file,
meaning that each time you want to add a module to reactos, you have to
edit this file. What I propose is to create this file dynamically, when
parsing the build system file. Adding a reactos module twould then be as
simple as (!) creating a new build file for this module.
For those who are concerned about slipstreaming or optional files like
wallpapers or whatever hacking they do with the current reactos.dff, it
will be as easy as before. There will be a file to edit, which will be
the "static" part of it. Whatever you'll write in this file will be
written back to reactos.dff, so there is no need to worry about that.
What do you think?
Regards.
Jérôme.
PS : The patch is there. It waits for your approval :-)
Where is my Server core style command prompt login? Screw explorer. Oh,
and I want RDP. ;0p
On Oct 27, 2010 4:18 PM, "Adam Kachwalla" <geekdundee(a)gmail.com> wrote:
We need to first fix up the logon screen. I have tried this, except the
problem lies with CreateDesktop() not wanting to create more than one
desktop within the Winlogon process.
At this stage, the logon/logoff functionality does not work at all, and some
processes still linger about.
It appears explorer shell is one of them.
On Thu, 28 Oct 2010 02:22:36 +1100, Javier Agustìn Fernàndez Arroyo <
elhoir(a)gmail.com> wrote:
> H...
--
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://ww...
Hello, devs!
ok, lets stop flaming and lets do anything useful 3:>
For the future:
will ReactOS support "true" multiuser sessions (that is, *simultaneously*)?
Is it possible?
that would be a big enhancement over Windows :)
I think that Wine Gecko should be integrated in the ReactOS releases. It
is needed IIRC for things like Winhlp32 (I think) and HTML Help
(defiitely) and applications which use IE browser controls.
Hi ReactOS friends and colleagues.
There have been exciting years, I first started to have an eye on the
freewin95 project. When I first found the ReactOS project and saw
that they actually gave away free zip-files with files to try it out
I was eager to test it my self, I first downloaded my first
“bochs-1.3-reactos-images.zip” the third april 2002, and it worked! I
was amazed, so I downloaded and tested everything that I could test.
A long time has gone since that time and I have seen a lot of
progress during the years, however it's a lot of years, for me about
nine years of downloading, compiling, testing and reading svn-
messages. For many people it has been too many years and many have
fallen away, now however we are close to something that can actually
be used, the kernel is pretty stable other parts of the OS is
improving and getting there too.
During the last many years we have had about 100 individuals in the
IRC channel at all time, it indicates in my mind that we attract as
many people as we loose, I guess that is kind of the status for our
project, we should be able to change that in a short while I think.
If we can release a some real-life applications for our OS we could
draw some attention that could be permanent and the project could
really start to grow for real.
I and Aleksey met in Björkvik, Sweden for a discussion on how to get
the ball rolling, we have some suggestions that could serve as step
stones for such development. The key is to release a package of the
project and see to that it can really do that but not everything
else, for example, a web server, it doesn't need all the OS but the
ones it needs it has to do really good.
Even with this in mind ReactOS isn't well suited for many real
applications, so we just looked at a few to see if it would be a way
to go, you could perhaps suggest some more, and we would welcome
that, we only have to ensure there isn't too much work to actually
come to the finish line. Here we present some ideas and what needs to
get in place to actually make it work.
Webserver
- Network subsystem (mainly tcpip.sys driver, and some winsock
improvement)
- VNC support (future RDP support)
- Apache/MySQL/PHP support
- XAMPP with toolbox
- WEBMIN
Thin Client (LiveCD or BootCD)
- Re-port our MSTSC.EXE
- Local printing (USB/LPT printer support?)
Please give us your opinion and please also add possible ideas that
you have and think through what needs to get in place to see it come
to pass.
Yours sincerely,
Aleksey & Jan (Jaix)
through Jan
Am 26.10.2010 18:01, schrieb jgardou(a)svn.reactos.org:
> +#ifdef __GCC__
> /* Note: this should return a CLIENT_CALL_RETURN, but calling convention for
> * returning structures/unions is different between Windows and gcc on i386. */
> LONG_PTR RPC_VAR_ENTRY
> @@ -659,6 +663,13 @@
> NdrAsyncClientCall( PMIDL_STUB_DESC pStubDescriptor, PFORMAT_STRING pFormat, ... );
> LONG_PTR RPC_VAR_ENTRY
> NdrDcomAsyncClientCall( PMIDL_STUB_DESC pStubDescriptor, PFORMAT_STRING pFormat, ... );
> +#else
> +CLIENT_CALL_RETURN RPC_VAR_ENTRY NdrClientCall2(
> + PMIDL_STUB_DESC pStubDescriptor,
> + PFORMAT_STRING pFormat,
> + ...
> +);
> +#endif
>
Is this hack even neccessary? I couldn't see any difference between gcc
and msvc with the correct prototype.
Both return the result in eax.
Hi,
good to see the branch work back in trunk, I suspected this work would be
left to rot and finally be forgotten (like in most other experimental
branches). Altogether this looks like a huge step forward, got to test those
mode switches it once I have enough time.
One thing I noticed from the diffs is the eng/mem.c file, which exceeded my
EVIL / HACK threshold. Is this supposed to stay - especially in the context
of ARM3's to be proven awesomeness?
--- snippet ---
EngSecureMem(PVOID Address, ULONG Length)
{ return (HANDLE)-1; // HACK!!! }
EngUnsecureMem(HANDLE Mem)
{ if (Mem == (HANDLE)-1) return; // HACK!!! }
--- snippet ---
Good work anyway, thanks to the people involved!
Regards,
Gregor
You could always run two installs in different directories.
On Oct 25, 2010 10:51 AM, "Bernd Blaauw" <bblaauw(a)home.nl> wrote:
Op 25-10-2010 16:09, Fan Zhang schreef:
>
> Thanks. But I don't know if i run ReactOS, how could I replace the kernel
file, such as ntoskrl...
So basicly running a ReactOS installation with RosBE installed as
application, sources downloaded and modified, and then you want a way to
update files from this ReactOS installation itself?
As long as ReactOS installs only on FAT filesystem, I guess you could use a
DOS bootdisk/installation to overwrite any files. It's not entirely
convenient.
Is there basicly a set of lists of ReactOS files for the following:
* which ReactOS files can be overwritten by a new file while you're still
running in ReactOS? .inf files? small games like solitaire?
* which ReactOS files can be overwritten, but require a reboot to be
properly noticed? some drivers perhaps?
* which ReactOS files require you to be outside of ReactOS in order to
replace them? ntoskrnl comes to mind, explorer I guess
All in all, mr Fan Zhang might be asking for some kind of update mechanism.
If you had an old machine which you run ReactOS on, together with same
casual data (audio files perhaps), do you need to reformat the disk to
update ReactOS? or only remove the installation directory? or pick a
different installation directory? or same directory? After all, you don't
want to lose any user data.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://ww...
Hi guys,
I want to know how do you debug ReactOS. For example, when I change the
code, I used to execute 'Make bootcd'. After that, I will install the
ReactOS system by ReactOS.iso. So I'm confused if I have to install the whoe
system after compiling. Do you have some easy way?
Thanks.
Fan
Hi,
I thought I would drop a line here finally :)
My name is Oleg, I am from Russia (some 180km from Moscow :)). I worked with
Aleksey many years ago on some kernelmode networking-related tasks for
Windows NT 4.0 and later Windows 2000. Your recent 0.3.12 release news was
all over the place here on Russian news sites, my congratulations! ReactOS
is a great project, though I never had enough time to actually start
hacking, but recent achievements seems to motivate me more.
What is situation with networking in ReactOS? I think this could be my main
direction of work. I would glad if someone writes a current state of
networking in ROS, so I would know where to start.
// Oleg Baikalow.
Hi everyone,
I'd like to announce that I'm soon going to merge yarotows back into
trunk, if no other regressions are found. The current issues (red icons
and blue text on disabled buttons will be fixed, Kamil has already a fix.)
Last chance to test and object ;-)
Regards,
Timo
I am currently checking our 0.3.12 milestones. And the milestones status is:
**********(Bug 5517)Some icons look wrong (blue background)**********
There is a Hack for the release.
**********(Bug5560): Adobe Acrobat Reader 7.1 throws exception at start****
This is a Wine regression. It is not in our hands.We have to wait for a Fix.
**********(Bug 5472) comctl32: Keyboard shortcuts don't work after winesync***
Not as bad as it sounds. It does not work just in 2nd Installation Stage.
Anyway, there is a Hack for this issue too.
**********(Bug 5314) REGRESSION: Acrobat Reader: pen leak*******
It is supposed to be fixed, but it is Bug5560 dependant so it is impossible to confirm the Fixed status.
**********(Bug 5598) PATCH: Opera 9.64, FireFox 3.0+ crash when using Russian/Lithuanin/Ukrainian locale****
Reverting the *.nls changes solves the issue.
There is a Hack attached.
**********(Bug 5482)REGRESSION: ExplorerXP: black background on treeview area*****
This is a Wine regression. It is not in our hands. We have to wait for a Fix.
**********(Bug 4106) REGRESSION: Wrong text spacing in popup menus / icons after show a font in control applet / Remote Desktop*******
It is a minor regression since it has been there for a while. Also Yarotows seems to fix some of the issues.
**********(Bug 5591) REGRESSION: devmgr: wrong icons in the TreeView *****
Updating comctl32 will fix the issues. Or we can revert the comctl32 changes.
**************
* Summing up *
**************
There are 8 regressions.
4 has different options to be solved (Hack or Wine update/revert)
2 are current Wine regressions (we have to wait for a fix or revert Ole32/Comctl32 changes)
1 could be fixed (the Acrobar Reader leakage) but we need to fix Acrobat first(reverting?)
1 is a minor regression without a solution ( "Bug 4106")
So we can solve 7/8 regressions. Is it time to think about a 0.3.12 release? It is time to take decisions (reverting/updating/waiting Fixes) since there are solutions.
I don't think having the Trunk frozen is good for the project.
So, opinions?
I think its a good time to discuss current development cycle.
It become clear to me, that there is no way we can currently adhere to 3
months development cycle. Its pointless to stick to something we managed to
succeed only once or twice.
Agreeing with the fact we do need releases, for various reasons, i would
like to propose a new, longer cycle.
The most apparent choices to me are 4 and 6 month ones. At least half of the
cycle would be spent on all out development, with the following half turning
its concentration to stabilizing trunk, searching for regressions and bugs,
fixing them. The cycles would be separated by branching the release version.
The actual release would be taking place on the first month of the NEXT
DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One
month is more than enough, to release two RC (at the branching and next one
- after two weeks). End of the month must result in final release. RC should
be rather released internally for testing purposes on a default iso.
The actual proposals are:
4 months:
month 1: Development on version x. At the same time, the Release x-1 is to
be final-tested, emergency-hacked, changelogged and shipped. The deadline is
end of month 1.
month 2: Development on version x. All development that can affect trunk
stability, but also will not be shipped with the release X should end or be
limited to branch only by the end of this month;
month 3: Switching from development more to stabilizing trunk, searching for
regressions, fixing bugs. Finalizing sub-projects that are to be included in
release x;
month 4; No new functionality/code, bug-fixing and hunting regressions. This
month should end with branching for release x;
6 months:
month 1: Development on version x. At the same time, the Release x-1 is to
be final-tested, emergency-hacked, changelogged and shipped. The deadline is
end of month 1.
month 2: Development on version x;
month 3: Development on version x. All development that can affect trunk
stability, but also will not be shipped with the release X should end or be
limited to branch only by the end of this month;
month 4: Switching from development more to stabilizing trunk, searching for
regressions, fixing bugs. Ongoing development work only for features that
are to be shipped with release x;
month 5: Switching from development more to stabilizing trunk, searching for
regressions, fixing bugs. Finalizing sub-projects that are to be included in
release x;
month 6: No new functionality/code, bug-fixing and hunting regressions. This
month should end with branching for release x;
Hi!
Since I'm starting to move around now and fell better. Let's just say,
I guess it's time to move from the window object and move to the wnd
one. I have two local branches here on the portable system, one for
Right to Left support (wine sync) I've started and the standard test
one. I would like to have all the available Win32 developers help out.
You too Ged! Try to get this done before to much goes into CMAKE and
have to rework it all.
>From window.h:
/* Scrollbar info */
PSBINFOEX pSBInfo; // convert to PSBINFO
/* Entry in the list of thread windows. */
LIST_ENTRY ThreadListEntry;
} WINDOW_OBJECT; /* PWINDOW_OBJECT already declared at top of file */
/* Window flags. */
#define WINDOWOBJECT_NEED_SIZE WNDS_SENDSIZEMOVEMSGS
#define WINDOWOBJECT_NEED_ERASEBKGND WNDS_ERASEBACKGROUND
#define WINDOWOBJECT_NEED_NCPAINT WNDS_SENDNCPAINT
#define WINDOWOBJECT_RESTOREMAX (0x00000020) // Set/Clr WS_MAXIMIZE &
#define WINDOWSTATUS_DESTROYING WNDS2_INDESTROY <----- "WNDS2"
state2 flag
#define WINDOWSTATUS_DESTROYED WNDS_DESTROYED <----- "WNDS" state flag
Move this to ntuser.h including the SBINFOEX too, not sure I did that
one yet, and start hacking it then test the hell out of it. The flags
just convert them to the correct ones, _RESTOREMAX may need more
research (another word for HAX).
Just writing this and it looks simple, but this is one file that
effects the whole w32k tree.
Thanks,
James
That will be hard to beat for r50000...
> Author: sir_richard
> Date: Tue Oct 5 15:59:47 2010
> New Revision: 49000
>
> URL: http://svn.reactos.org/svn/reactos?rev=49000&view=rev
> Log:
> [NTOS]: Fix whitespace typo in comment (two spaces instead of one).
> That's right. I'm not a fun person.
>
This is a possible fix for the initialization problem reactos suffers
from. Just let me know, how it goes with testing. ATM QEmu works okay
and no hardware test was run.
Thanks,
James
LOL!
Keeping it from running off the side of the page! Know one told you!?
The screen is flat! If you go out to far, the characters will fall
off!
@@ -217,7 +216,8 @@
!(pEH->Flags & WINEVENT_SKIPOWNPROCESS)) ||
!pEH->idProcess ) )
{
- Result = co_IntCallEventProc( UserHMGetHandle(pEH),
+ // What in the deuce is this right-aligned formatting?
+ co_IntCallEventProc( UserHMGetHandle(pEH),
Event,
UserHMGetHandle(pWnd),
idObject,
I'll audit your code and commit ass cocking comments too........
James