That's a good first step into using proper winsock!
WBR,
Aleksey Bragin.
On Jul 26, 2009, at 10:00 AM, cgutman(a)svn.reactos.org wrote:
> Author: cgutman
> Date: Sun Jul 26 08:00:32 2009
> New Revision: 42225
>
> URL: http://svn.reactos.org/svn/reactos?rev=42225&view=rev
> Log:
> - Begin using ws2help_new
> - I have tested this with various applications in ROS
> - Part 2 of 2
>
> Added:
> trunk/reactos/dll/win32/ws2help/ (props changed)
> - copied from r42178, trunk/reactos/dll/win32/ws2help_new/
> Removed:
> trunk/reactos/dll/win32/ws2help_new/
Hello all,
Now that also the mail migration is more or less completed, let me introduce
you to IServ.
IServ is a Groupware solution, which we will be using now for managing
E-Mail accounts, appointments, contact data and a common FTP space. It will
be available to everybody, who is qualified for a @reactos.org E-Mail
address. (so basically developers with SVN access and official testers)
For your @reactos.org E-Mail address, IServ provides a 250 MB mailbox. You
can send and receive E-Mails over the Web interface and also over POP3, IMAP
and SMTP.
The Web interface also offers an option to set up a redirection if you want
to use another mailbox for incoming mails.
Files can be uploaded either over the Web interface or over FTP.
Our IServ Web interface is available at http://iserv.reactos.org. The POP3,
IMAP, SMTP and FTP services can be accessed over the same domain.
If you have an @reactos.org E-Mail address, but no IServ account yet, I will
shortly send you your account name along with an initial password.
Your account name will also serve as your primary E-Mail address from now
on. (i.e. colin.finck(a)reactos.org). Of course, your previous E-Mail aliases
will continue to work. They are linked to your primary address now.
As most of you used a redirection from your @reactos.org address to another
mailbox, I've set up these redirections in the Web interface already. You
can change them anytime.
A big thanks go to Martin von Wittich and the IServ GmbH, who provided us
with a site license for IServ and helped us with the setup.
Also thank our translators Amine Khaldi, Gabriel Ilardi and Alex/care2debug
for the French, Italian, Spanish and Russian translations of the Web
interface.
Best regards,
Colin
As you all know, reactos is tested against the wine test suite. While
this is a great tool, I think this is not enough to be sure that ReactOS
is fully tested.
I've been trying to fix some kernel32 tests. As you all know, in ReactOS
it is written on top of ntdll. So I wanted to fix some tests, and then a
question arose : is it that kernel32 calls ntdll the wrong way, or is it
that ntdll does the wrong job? The only way to verify this would be to
test kernel32.dll out of reactOS, meaning replacing the windows one with
the reactos one, and run the test.
To be brief : I think that a weekly "reactos dlls against windows" test
would be very helpful to be sure that things are done the right way!
I began with the kernel32:file winetest. I managed to not make it crash
when used on winXP, the resulting patch is there :
http://www.reactos.org/bugzilla/show_bug.cgi?id=4728 and the result of
this test is attached there. As miracles happen, it also fixes some
tests on ReactOS. Seems like this is a good approach.
Jérôme Gardou (aka zefklop on IRC and forums)
This explains why we are using a trampoline function and not just
typecast there... Is there a reason you changed this?
- Thomas
dchapyshev(a)svn.reactos.org wrote:
> - /* NOTE: Don't use Function directly since the callback signature
> - differs. This might cause problems on certain platforms... */
> - Status = RtlQueueWorkItem(InternalWorkItemTrampoline,
> - WorkItemContext,
Hello,
I've heard many question about a branch I was working on recently,
arwinss, so I'd like to write some explanation (you may skip the
boring history part of the message)
Arwinss is a rewrite (the most advanced so far out of all previous
attempts) of some parts of the Win32 subsystem, namely the USER32 and
GDI32 API interfaces, along with the kernel counterpart win32k.sys.
The kernel32.dll, csrss, and other parts remain in their present
condition, and getting bugfixes if they come in the way of a rewrite.
[History and reasoning part starts here]
Why rewrite and not fix an existing Win32 subsystem? Timo, James and
all our other great developers were and are doing a great work. I put
a considerable amount of time in it to fix problems too. But, since
our project is a volunteer-driven one, everyone has a real life, real
work to do, and is not able to sit 24 hrs researching Windows
internal structures, inventing new algorithms, trying out thousands
of applications, not to say about graphics drivers.
Time is ticking, Win32 is improving, but most annoying bugs are there
for years - e.g. vmware installer hang, Firefox move the mouse bug,
drawing glitches, concurrency hacks in the code ("if (!a) /* someone
else was faster than us and already freed it */"), probable heap
misusage (relying on our heap implementation for desktop heaps) and
heap memory corruptions (I kept trying to update rtl/heaps to the
newest Wine code - and always failed without any obvious reason),
inability to change video mode on the fly, and the list can go on.
So I thought, that something should be done with it. I would even
want to trade off some speed gain in favor of stability (optimizing
is an enjoyable task which could be done later).
After teaming up with Stefan, we created an nwin32 branch - a totally
stubbed out win23k, user32 and gdi32. They had exactly matched
exports, and win32k had exactly same system calls and Windows 2003
SP1's win32k.sys.
However, due to really huge amount of work, the branch didn't went
farther than trying to boot Windows 2003 with it and see a few
stubbed functions being called.
Since then I started thinking on an alternative design of a Win32
subsystem. The idea turned out to be very simple, and is based on the
following questions:
- Why put so much effort into keeping the internal win32k system
calls interface the same as in Windows, why put so much effort in
converting to internal Windows structures, if we don't have something
working first?
- Why base on a stoneage Wine's code which James and Christoph
occasionally sync, and all my attempts to get more people into this
boring task failed?
- Why not use achievements of our closest project - Wine?
[End of reasoning, fancy stuff starts]
The result came by itself: Try to build up a win32 subsystem based as
much on Wine code as possible, and using Wine's modular design.
Before publicly announcing it, I have spent a month actually trying
all that stuff, and surprisingly it went very well, and a nice
byproduct: support of remote sessions via X Windows.
Proof of concept screenshots are here:
http://www.reactos.org/media/screenshots/2009/arw_xlog1.jpghttp://www.reactos.org/media/screenshots/2009/arw_xlog1.jpg
Noone has ever done this before: This is Windows 2003 inside VMware,
running my custom Win32 subsystem, with an X graphics driver module,
communicating with an X Server running in the host OS (Windows XP,
XMing X windows server), and with ReactOS's winlogon.exe and
msgina.dll (for ease of debugging and source code availability)!
Let's go straight to the architecture:
GDI32.dll and USER32.dll are ported Wine usermode code, with very few
modifications. GDI32 and USER32 depend on two things: Gdi and User
driver, and a server.
Gdi and User driver is a loadable DLL, which provides an abstraction
of a graphics driver in the system through a certain set of APIs. A
typical example of such a driver is winex11.drv, which routes all
drawing to the X Windows "client". However, this is not very useful
for a local system which has a Windows NT architecture, where there
is no need for remote windows displaying.
The server. GDI32 and USER32 rely on the server for managing all
global information. In Wine, the server is run as a usermode
wineserver.exe process, which communicates with gdi32/user32 via
custom RPC, and emulates quite a lof of stuff which Windows NT kernel
provides by default. My decision was to convert the RPC protocol from
a slow interprocess filedescriptors-based unix-specific invocations
to a fast system calls to win32k module. This way, win32k contains
small part (~300 kb vs 1.5Mb+) of wineserver's source code, which
deals with windows, window classes, atoms, windows stations, desktops
and other totally platform/implementation independent stuff. It will
be reduced further, because I even ported their own object manager
for win32 objects, which will be exchange to our native ntoskrnl's
object manager soon, when the testing phase is over.
The graphics driver, kernelmode part. As I said above, it's not very
convinient to fully rely on X Windows for graphics output, because
it's just not possible to run it in an NT-based OS which has no Win32
subsystem. Thus, I decided to create a totally native gdi/user driver
("winent.drv"), which would rely on win32k module to actually perform
all drawing. However, compared to our current implementation, the
drawing would be way more simple. For example, if currently LineTo
operation in win32k involves complex PATHOBJ, maintaining graphics
cursor -- all of that in a strictly windows compatible way because
apps depend on it, in this alternative win32k, LineTo is a simple
line drawing function: RosGdiLineTo(pDc, x1, y1, x2, y2). Same
applies to other functions, including e.g. text output, where all
rendering happens using a usermode freetype.dll, and win32k just
needs to display bitmap glyphs got from gdi32.
Don't be scared if you don't understand all that right away. I will
put up a good short summary, along with a TODO and FIXME lists, and a
HACKING guide.
Just a few cool facts about the new win32 subsystem:
- Based on a solid, very well maintained codebase, used by commercial
vendors.
- Ease of updating from upstream (vendor importing)
- Tested against more than 12 000 Windows applications (http://
appdb.winehq.org)
- ...
I think it's enough for the first introduction.
WBR,
Aleksey Bragin.
Well, after some extensive revision hunting, the strange keyboard bug some people (notably VBox users and people on RHW) has been traced to r41291 (the commit that activated USB keyboard and mice support)
Now, i know this isn't an "important" bug, but it's a bug none-the-less. It's up to the devs to decide what to do with it, but i thought it was worthy of looking into.
Also, rather interestingly, this bug seems to be restriced to debug builds only. The (very few) release builds i have tried seem perfectly free of this bug,which seems rather stange to me.
It's getting rather late now, but i'll probably try and get a debug log of r41291 sometime tommorow, so i'm sory i can't do any more tonight. Please post here with your experience of this bug! :)
Yours sincerely
Joshua Rice.
Hello all,
As most of you probably noticed, the downtime of the website was quite long
now due to the server migration.
But finally, we switched the DNS records of the ReactOS domains now, so as
soon as the DNS servers around the world got the update, you should see the
website again at the new server.
So far, the migration only affected the Website itself. Originally, we
planned to do the mail system migration as well on the same day, but ran out
of time due to some unforeseen problems with the Website migration.
This also means that you currently cannot send any E-Mails from our web
services (such as Bugzilla and phpBB). Also the mailing list archives are
currently not available.
Anyway, we're going to do the mail migration in the next 24 hours and target
these problems by then.
After all, let's come to some advantages of the upgrade:
First of all, we finally upgraded to RosCMS version 4. This version was
mainly developed by Danny and went through beta testing for quite some
months now. Some of the new features it provides include dependency handling
(so you don't need to regenerate all pages affected by your change
manually), a faster generator and a much better codebase.
Secondly, there should be notably performance improvements. A component that
especially benefits from them is Bugzilla.
Besides, we don't use a reverse-proxy for static pages any longer. This
means as much as that you don't have to press Ctrl+F5 anymore to see updated
web pages, which weren't noticed by our caching proxy.
Just try the Website out now and if you find any problems not mentioned
here, post them to this list or try to contact Danny or me on IRC directly.
Best regards,
Colin
Hyperion is riht here; take a look at WINE code then look at ros...WINE appears much more professional than ros code. Good luck aleksey.
------Original Message------
From: KJK::Hyperion
Sender: ros-dev-bounces(a)reactos.org
To: ReactOS Development List
ReplyTo: ReactOS Development List
Subject: Re: [ros-dev] Arwinss
Sent: Jul 20, 2009 8:47 AM
Timo Kreuzer wrote:
> Wine emulates the kernel through a server. Of cause we don't use it,
> because it has a totally different design.
Says who? So far, and only counting official implementations, Win32 has
been implemented as:
- a shared-memory user mode subsystem (Windows 95, 98)
- a RPC user mode subsystem (Windows NT 3)
- a kernel mode subsystem (Windows NT 4 and later)
- ??? (Windows CE)
> We have an NT kernel and
> every kernel developer would eat me alive if I tried to put a single
> line of wine code into our kernel. It's considered crap there.
Wine code has to pass quality reviews and test suites. ReactOS code only
has to pass the warmth-and-fuzziness test. Wine can prove their code is
right, ReactOS is based on code that feels right
The idea that Wine code is better than ReactOS code really needs to die.
Compared to theirs, our code is sloppy, highly unprofessional and often
inexplicable. We copy the form but tend to completely miss the intent.
Wine development is test-driven and entirely based on intent and end
results, while our development model is, apparently, to dick around in
our spare time pretending we work at Microsoft
> How do you expect display drivers to work at all?
NT display drivers used to run in user mode with the same identical API,
and probably the same ABI. I'm sure Aleksey will do just fine
> More hacks on top of the huge pile of hacks? And how do you deal with
> missing functionality in wine code? Shove more code in there? Or ignore
> it, like if wine doesn't need it, we also don't need it? Or again fork
> the code?
I would sell my mother to Carthage for even a fraction of the kind of
application support that Wine enjoys, thank you. My only gripe with
arwinss is that Aleksey beat me to the first landmark controversial side
project
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Sent on the Sprint® Now Network from my BlackBerry®
Hello,
We're planning to migrate the Web and Mail system to a new server and
upgrade these components in the next 24 hours.
This affects the whole Website at www.reactos.org plus all @reactos.org mail
addresses including the mailing lists. During the migration, these services
may be temporarily unavailable.
The Web server migration includes upgrading the server components (e.g.
Apache, MySQL, PHP) and applications (e.g. RosCMS, phpBB) to newer versions.
Besides, the configuration of the server components was tuned for a better
overall performance.
The mail boxes, mail relays and mailing lists will be moved to a dedicated
virtual machine, which will also offer a groupware system for official
ReactOS developers and testers.
Our plan is to do this upgrade in two big steps, namely first the Website
and afterwards the mail stuff, to keep the downtime as low as possible.
Minor problems are expected after the migration and will be fixed shortly.
In case of major unforeseen problems, the downtime of particular components
might be extended to the next 48 hours.
Best regards,
Colin Finck
I think that part you removed was right, because that is ntdll's job.
Wine, for historic reasons, have this code in kernel32, which is wrong.
Same applies to the LoadLibrary call.
WBR,
Aleksey Bragin.
On Jul 17, 2009, at 9:15 PM, dchapyshev(a)svn.reactos.org wrote:
> Author: dchapyshev
> Date: Fri Jul 17 19:15:17 2009
> New Revision: 42005
>
> URL: http://svn.reactos.org/svn/reactos?rev=42005&view=rev
> Log:
> - Re-implement FreeLibrary (for support LOAD_LIBRARY_AS_DATAFILE)
> - HeapAlloc -> RtlAllocateHeap, GetProcessHeap ->
> RtlGetProcessHeap, HeapFree -> RtlFreeHeap, CloseHandle -> NtClose
> - Remove FIXME in LoadModule
>
> Modified:
> trunk/reactos/dll/win32/kernel32/misc/ldr.c
On Fri, Jul 17, 2009 at 8:49 AM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Fri Jul 17 14:49:16 2009
> New Revision: 42000
>
> URL: http://svn.reactos.org/svn/reactos?rev=42000&view=rev
> Log:
> - Create a branch for upcoming work.
>
> "<XXX> people will eat you alive anyway so it doesn't really matter"
And your going to make children cry when people see what your doing...
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
It seems to have been come a ReactOS tradition, that every 2 / 3 weeks
somebody turns up on the mailing list and shows her / his _unbelievable_
exciting groundbreaking phenomenal concept which will bring us to beta
and save our boring sad, depressed sucicidal lifes. I do honor your
efforts, but
I can only speak for myself:
1) I do coding ReactOS for fun
2) I do coding ReactOS because I enjoy the challenge
Please keep your ideas for yourself unless you come up with a business
plan!
Thanks
Johannes
Hello everyone. I find myself today thinking, as I sometimes do, about the
ReactOS problem. How come we are trying to clone the biggest and arguably
the most popular desktop OS in the world and still have such a small
community/user base?
The obvious answer to this question is that ros doesn’t do what it promises.
Indeed it does almost run a lot of windows applications... some of the time,
but that’s not the whole picture. Let us examine the typical(in my
experience) first time encounter of a random computer user with reactos.
<fanboy> Look, this is a free open source windows clone called ReactOS. It
has solitaire and runs firefox. Awesome, isn’t it?
<noob> so does it run my windows drivers and Office and COD4 and… !?
<fanboy> well…. Umm… not really.
Let’s analyze what went wrong:
*1) *ReactOS base distribution is fine and great, I totally like my
reactos with just a cmd window and dwnl.exe; but it’s not enough, except
perhaps for someone that’s *extremely* motivated to do
*something*interesting with ros.
**
The solution, host a reactos distribution. I think its been proven that the
reactos community doesn’t want to host more 3rd party code in the repository
unless it’s absolutely necessary. But that doesn’t matter. We don’t need to
build firefox, mono, or anything from source. The Windows model of software
distribution is binary. There doesn’t have to be an update manager, reactos
is just a toy(more on that later) and it needs to look useful so that people
buy into it. Maybe a nice list of packages and some checkboxes in second
stage installed with a script…
2) Hardware support is very poor, on recent hardware it almost never
works(wild guess 75% fail rate on modern hardware) Problems range from
unsupported video cards/ros driver uses wrong/unsupported mode, wrong
storage bus, random crashes from unsupported usb devices + pcmcia
other similar
alien buses and just random bullshit. Even if nothing manages to bring down
reactos, it of course has the wrong nic card and since usb storage doesn’t
exist there’s no chance to get a driver and see ros crash because of course
we only support a couple of drivers.
I know this can’t just be magically fixed, but we need people dedicated to
do hardware testing/debugging and provide real bug reports with traces.
(Suggestion: allow kdbg to take ownership of the screen/give it back,
provide visual console. I don’t care if it’s not a windows feature.)
3) Who cares about all the above? Not noobs, the question they really
ask is: “Does it run XYZ?”
What is XYZ? Flagship applications. The ones everyone knows and uses,
commercial and opensource. The following, I think, are universally
recognized as very important.
a) Firefox + Flash (this works most of the time… maybe god will kill
that mouse move bug)
b) A recent version of Microsoft Office. (2007 would be very nice)
c) Latest OpenOffice( imagine a make distro command that would tell
ros setup to install it automagically, wouldn’t that make testing easier…
heck we could have a super build bot that wrote documents in office and
compiled shit with gcc and took 3 days to run….)
d) .NET Framework (atleast 2.0) (This means fixing its installer bug)
e) Java runtime. (it installs and almost launches limewire!! Christ!!)
f) Visual Studio 2008 (installer fails, but the c++ compiler works and
the IDE almost works!!)
g) Recent versions of Adobe Photoshop, Dreamweaver or Flash.
Extra points:
h) Msn Messenger (its expected by windows users)
i) Internet Explorer (screenshots floated around at some point with
IE6, I think.. or maybe it was a dream)
j) Virtual Box (with its drivers!) ( I just love the vm inside vm
screenshot)
k) Nmap (only pcap driver is broken!)
l) Silverlight (seems to install)
m) Itunes (with ipod support)
(please dont be pricks about this list, make a poll or something if you
must, but someone has to arbitrarily set it)
The sad truth is that most of these applications are known to work to a
certain degree. However, good bug reports don’t even exist. I’m confident
that with a bit of determined effort these apps can be made to work. Atleast
we need to compile a list of whats missing in ros that is need to support
these and other important applications with real bug reports, and focus the
project... give defined tasks to noobs that stumble into the project but are
not knowledgable enought to dive into our huge code base and decide what are
the missing features/features that need work/bugs.
But really, what is the point of this email…
0.4.0 will be a milestone release(nice round number), people really want
these and other similar applications to work(perhaps they are the reasons
people still use windows). It makes sense to try and support them and would
provide a nice PR boost if 0.4.0 can honestly be said to support any or all
of the above applications.
ReactOS is a developer toy, a cute little model of windows that almost
works. If we can at least make it work for applications that most users
actually use we could maybe, oh I don’t know… spark some interest. Yes, it’s
about users, which we still won’t condone being alpha and all. But users are
the ones that get excited and twitter and facebook and blog about the little
OS that could; Excitement that will get developers exited, that will provide
testers (I’m praying for some sort of reactos error reporting service,
atleast a minidump….. atleast in usermode… support event logs…. for Christ
sakes our bug reports suck and they suck10x worse when they come from
noobs!).
Right now we are stuck in the vm, so atleast make that experience enjoyable.
There’s no need to rant about explorer, I hope…
We have to start thinking about 0.5 and making reactos “beta”, and I still
haven’t seen plans on how that’s going to happen or what exactly that means.
ReactOS development needs to speed up and get more organized….. that’s all I
have to say about that…. probably not…
Hello all,
Open-source and newcomers
~~~~~~~~~~~~~~~~~~~~~~~~~
I've been here for 2 weeks already and I want to share some thoughts
from the point of view of a newcomer.
I want to make a claim as an axiom and see where it goes from there.
If you don't agree with the axiom you should probably read something
on ethology and group behavior.
I beg you to be open-minded.
--
So the axiom is:
"A closed group of humans (and many other social animals) usually
is emotionally and irrationally unfriendly to newcomers, due to
the evolutionary baggage we all share."
The group assumes a hostile position to a newcomer. Many members don't
realize what is going on. It simply feels like: "I just hate this guy!"
Members, of course, feel special and somewhat better, just because
they are part of the group. They see newcomers as not-worthy to some
extent, just because the newcomer is not in the group. They see the
newcomer as an alien and – as a threat. Subconsciously. Don't bother
to reply and tell me that I am not-worthy to be seen as a threat :)
The general feeling is "Who the f#ck he thinks he is? He's not from
our group, he is not one of us (he didn't do anything to our project
yet). Blah-blah-blah... I just hate this guy!". This irrational hate
is very tangible, believe me. It is very de-motivational. (And I
probably shouldn't have reacted the way I did to some of it, but, hey,
I am no Jesus Christ, and it's only now that I've sorted those things
out for myself).
But you can say: Hey, we are not hostile, because:
- "I, personally, entered the group in the past and it was Ok."
- "Look at that guy and that guy – we were soooo nice to them!"
Let's see... When can a closed group readily accept a newcomer?
When it doesn't perceive him as a threat.
This means the newcomer must come in a very submissive pose and
exhibit not a slightest sign of aggressive attitude. Actually, the
more you cry for mercy, the more chances are that you will be easily
accepted into the group. Broken leg or being a total looser may help,
as compassion will start to overtake the initial hostility.
The "pose" on the text-based Internet is mainly how one talks.
This is an example of a submissive pose:
"Oh, Great Lords, you are so cool and I am not worthy. I beg you to
let me develop for ReactOS, I am not much, but I will dutifully learn
from you, Wise Masters, I will catch every word you say and ignore any
insults you will throw my way. I will not criticize you in any way.
I will do all the shitty tasks silently and obediently for several years
until I slowly climb your social ladder. I will not complain of being
called stupid and not-worthy 'cause that's who I am..."
And so it goes... An ass-kisser, to be short.
And then the Wise Great Masters will generously allow this no-worthy
worm into their Temple.
This happens everywhere. Just take a closer look.
--
But this constitutes a problem. The group acts as a filter that favors
the wrong kind of people.
Because a good developer, after all, is usually opinionated, criticizes
what he thinks is wrong, doesn't like to be called stupid and be given
insults and shitty tasks. He challenges existing routines and things
the group got used to. He is a threat.
--
Unfortunately, I do not have a solution. I just want to attract your
attention to it.
P.S. You may ask – didn't you think that this hostility is a
consequence of you being a jerk? If being a jerk means not kissing
asses of Great Masters – then yeah, I may be guilty of that.
P.P.S. Before posting a reply, please take a look inside you and try
to see if that reply is based on "I just hate this guy!" :)
Thanks!
--
Best regards,
Alex mailto:care2debug@gmail.com
Hello ReactOS,
I am not sure if this is an appropriate place to write, but someone
with the name Physicus has banned me from the #reactos channel,
because he doesn't know physics and is ignorant enough.
Ok, you want to stay ignorant - it's your life choice.
But what right does he have to ban me from _reactos_ channel?
So now I can't develop for ROS, just because one guy is closed-minded
about his view of physics?!!
Is it how you treat people around here? No wonder you have such a
small number of developers...
Human stupidity and arrogance has certainly no limits...
--
Best regards,
Alex mailto:care2debug@gmail.com
#reactos is not ##physics, so you weren't on topic. If this email is an
example of your behaviour, I probably would have banned you too.
-WD
On Jul 15, 2009 7:30 PM, "Alex" <care2debug(a)gmail.com> wrote:
Hello ReactOS,
I am not sure if this is an appropriate place to write, but someone
with the name Physicus has banned me from the #reactos channel,
because he doesn't know physics and is ignorant enough.
Ok, you want to stay ignorant - it's your life choice.
But what right does he have to ban me from _reactos_ channel?
So now I can't develop for ROS, just because one guy is closed-minded
about his view of physics?!!
Is it how you treat people around here? No wonder you have such a
small number of developers...
Human stupidity and arrogance has certainly no limits...
--
Best regards,
Alex mailto:care2debug@gmail.com
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
> (Descriptor->Flags & CM_RESOURCE_INTERRUPT_LATCHED)
Is this right? ReactOS' KeConnectInterrupt() does not support
interrupts edge-triggered and shared.
Hello,
SVN server is going to be down for some time within the next 24hrs
due to transfer to another datacenter. Minor problems after the
transfer are expected and will be fixed appropriately.
Thanks for your patience.
WBR,
Aleksey Bragin.
ros-arm-bringup(a)svn.reactos.org wrote:
> stop building ntdll as a win32dll so we can fucking stop auto-importing mingw_common and kernel32 into it...
if you need any rbuild features or fixes, just ask me
> it's supposed to be built as a /SUBSYSTEM:WINDOWS dll
not even that, it's a DLL built with a subsystem of CONSOLE! (no idea
why, what the hell, Microsoft?) which rbuild can't currently express in
any way but <linkerflag>. Do you need a "subsystem" attribute for
modules, maybe? Knock the table once for "no", twice for "yes"
Commit: use %zd for SIZE_T, not just %d
File affected: trunk/reactos/tools/rbuild/backend/mingw/mingw.cpp
Replication: clean build, then try to make. Rbuild throws an unhandled
exception:
Faulting application rbuild.exe, version 0.0.0.0, time stamp 0x4a58b510,
faulting module msvcrt.dll, version 7.0.6002.18005, time stamp 0x49e0379e,
exception code 0xc0000005, fault offset 0x0000e461, process id 0x164c,
application start time 0x01ca023f7e2b558b.
when creating makefile.auto:
BASEADDRESS_WININET := 0x70200000
BASEADDRESS_WINMM := 0x697d0000
BASEADDRESS_WINSCARD := 0x723d0000
BASEADDRESS_WINSPOO
Please fix or revert the blamed revision, as it breaks buildint on Windows.
After r41859 installation in vmware (6.5) does not work.
Log:
(ntoskrnl\kd\kdio.c:220)
-----------------------------------------------------
(ntoskrnl\kd\kdio.c:221) ReactOS 0.4-SVN (Build 20090711-r41859)
(ntoskrnl\kd\kdio.c:222) Command Line: NOGUIBOOT DEBUGPORT=COM1
NOGUIBOOT DEBUGPORT=COM1
(ntoskrnl\kd\kdio.c:223) ARC Paths: multi(0)disk(0)cdrom(159) \
multi(0)disk(0)cdrom(159) \reactos\
Used memory 523828Kb
(ntoskrnl\mm\mminit.c:183) Start End Type
(ntoskrnl\mm\mminit.c:184) 0x80000000 - 0x80E00000 Boot Image Mapping
Region
(ntoskrnl\mm\mminit.c:187) 0x80E00000 - 0x81100000 PFN Database region
(ntoskrnl\mm\mminit.c:190) 0x81100000 - 0x87500000 Non paged pool region
(ntoskrnl\mm\mminit.c:193) 0x87500000 - 0x8D900000 Paged pool region
(ARM³::INIT:504) 0xB0000000 - 0xB0300000 Shadow PFN Database
(ARM³::INIT:509) 0xB0300000 - 0xB1318000 ARM Non Paged Pool
(ARM³::INIT:583) 0xF3400000 - 0xF8BF8000 System PTE Space
(ARM³::INIT:586) 0xF8BF8000 - 0xFFBE0000 Non Paged Pool
Expansion PTE Space
(ARM³::POOL:265) Out of NP Pool
(ARM³::POOL:393) Start of of initial frame
(ARM³::POOL:332) End of initial frame
[7hEntered debugger on last-chance exception (Exception Code:
0xc0000005) (Page Fault)
Memory at 0x00000000 could not be written: Page not present.
kdb:> bt
Eip:
<b0309000>
Frames:
<00000000>
kdb:>
--
WBR,
Dmitry Chapyshev
hyperion(a)svn.reactos.org wrote:
> Author: hyperion
> Date: Thu Jul 9 00:32:50 2009
> New Revision: 41815
This should fix the bug exposed by ARM3 and hackfixed by hto (see
#4663). I was in a hurry when I committed and I forgot to thank Stefan
for providing the regression test that was fundamental to fixing both
this issue and the previous PSEH2 bug
On the other hand, this PSEH bug has locked up our buildbot for a
considerable amount of time. I have no intention to promote hacking or
hiding bugs, on the other hand though, the longer we run without debug
buildbot, the more regressions and other problems are potentially going
unnoticed. This was my major concern over so called MDL probe or as we now
know - PSEH2 bug issue.
I decided to make this as a separate post, though it's a follow up to
the previous one.
I would like to set, officially, a couple of simple code hacking
rules, which are going to apply immediately for the NTOSKRNL module,
and to other modules after discussion/acceptance. They apply only to
committers (which commit their own or someone else's patches).
1. If you change someone's code, and believe it's a correct change -
go ahead and commit.
2. If you need to add a hack to someone's code, and:
2.1. you want to either hack or revert the offending commit which
breaks booting: This is allowed only after 24hrs after trying to
contact the author / posting to the ros-dev mailing list about the
problem.
2.2. you want to either hack or revert the offending commit which
contains a certain regression but doesn't cause important
consequences like inability to install the OS, or major loss of
functionality: This is allowed only from permission of author of the
code which you want to hack or, as alternative, from my permission.
I think this way we can get some order into the coming commits flow,
which is hard to track.
Also, please comment on this, so that we can alter those rules and
maybe accept them for all modules.
Thanks for understanding,
Aleksey Bragin.
This looks hackish
It also breaks the log as you're potentially returning something different from what the log states
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cgutman(a)svn.reactos.org
Sent: 06 July 2009 08:54
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [cgutman] 41783: - Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success
Author: cgutman
Date: Mon Jul 6 11:54:28 2009
New Revision: 41783
URL: http://svn.reactos.org/svn/reactos?rev=41783&view=rev
Log:
- Fix return value of tdiGetMibForIfEntity so it doesn't return a failure status on success
Modified:
trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c
Modified: trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/ifenum_…
==============================================================================
--- trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/iphlpapi/ifenum_reactos.c [iso-8859-1] Mon Jul 6 11:54:28 2009
@@ -280,7 +280,7 @@
entry->ent.if_descr);
TRACE("} status %08x\n",status);
- return status;
+ return STATUS_SUCCESS;
}
NTSTATUS tdiGetEntityIDSet( HANDLE tcpFile,
Uhm, why hack the kernel again? Testing on the buildbot was fixed to
accept this, so there is no urge. I was just trying to help RPG to
find the issue, along with vmware/vbox video drivers regression, due
to a MmMapIoSpace(128Mb) call.
Please read the next email.
WBR,
Aleksey.
On Jul 6, 2009, at 10:28 PM, dgorbachev(a)svn.reactos.org wrote:
> Author: dgorbachev
> Date: Mon Jul 6 22:28:11 2009
> New Revision: 41788
>
> URL: http://svn.reactos.org/svn/reactos?rev=41788&view=rev
> Log:
> "Fix" MDL PROBE FAILED! bug #4663.
jimtabor(a)svn.reactos.org schrieb:
> Author: jimtabor
> Date: Sun Jul 5 06:21:35 2009
> New Revision: 41776
>
> URL: http://svn.reactos.org/svn/reactos?rev=41776&view=rev
> Log:
> - Implement the client shutdown procedure. Tested with wine user32 msg undocumented 0x3B tests. Wine tests: msg: 6175 tests executed (0 marked as todo, 937 failures), 5 skipped.
> - Add missing end session types.
> - Reference: winproc.c WM_CLIENTSHUTDOWN http://wiki.winprog.org/wiki/Windows_messages
>
> [...]
>
> + List = IntWinListChildren(pWindow);
>
Oh, how I loathe this function.
It walks through the chain of windows to count them, allocates a buffer
from paged pool. Walks through the chain again, fills the buffer with
the windows' handles and returns the buffer so that the calling function
can walk through the buffer and use the handles to query the pointers to
the windows again. And this all happens while holding the global user lock.
Hint: you can remove 11 lines of code and change 2 lines and get the
same result, only faster.
Regards,
Timo
On Fri, Jul 3, 2009 at 5:53 AM, <dchapyshev(a)svn.reactos.org> wrote:
> - if (-1 == (int) Res || ! Res)
> - {
> - return Res;
> + if (-1 == (int) Res || !Res)
> + {
> + return FALSE;
I know you didn't write the check and were just changing the return
values but as a matter of style could we do something like
if (((int) Res || !Res) == -1)
or would the extra parens mess up the order of operations? Not a big
deal, its just easier on my eyes.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I think we all agree that the process of filling out a changelog is a task
we would rather avoid.
Collibri has made some efforts to alleviate this and despite getting some
good results we're also seeing a lot of information which isn't changelog
oriented. This now leaves us with a new problem of having to manually go
through data output from Collibri's tool and reformat it.
This is arguably more time consuming than the original method and isn't
working for us in its current form.
The current problem with this method is that a commit log is not a changelog
and getting something which can be classed as a changelog from this without
human intervention is an impossible task. There are also some people who
would rather write their own changelog instead of allowing a tool to
generate it for you.
The problem as I see it is two fold :
- Commit messages generally contain cryptic message, humour, idioms
and frustration
- Patches can spread over a wide range of modules making it
difficult to insert them into the correct position in the changelog.
A possible solution to this is to wrap up a changelog in XML elements. Such
a commit log would be as follows :
............................................................................
..........................
- Stop mixing unicode and ANSI strings
- Don't dereference NULL pointers
<changelog>
<notepad>Converted the application to Unicode</notepad>
<user32>Fixed a crash highlighted via adobe acrobat</user32>
</changelog>
............................................................................
..........................
This will allow anyone who wants to have a changelog autogenerated at
release time to take advantage and anyone who wants to do their own to
ignore it.
The problem with this method lies in getting the XML tags correct.
Anyone have any other ideas?
Ged.
Sorry for not deleting the post content:/
Back to sysreg... i`d issue a deadline, like 24-48h and until then i`d lock
the trunk. If this issue is not fixed until the deadline, offending revision
should be reverted and trunk unfrozen.
I can only hope we arent getting many regressions in the meantime.
Hi all,
As talked with Aleksey i would want to let you knwo that revision r41685 is
broken, in my real hardware, at least.
This is the log i get, im sorry to say i cannot give you more details
(backtraces, disasm´s, and so, since even kb does not work after the crash.
(ntoskrnl/kd/kdio.c:221) ReactOS 0.4-SVN (Build 20090629-r41685)
(ntoskrnl/kd/kdio.c:222) Command Line: NOGUIBOOT DEBUGPORT=COM1 NOGUIBOOT
DEBUGPORT=COM1
(ntoskrnl/kd/kdio.c:223) ARC Paths: multi(0)disk(0)cdrom(159) \
multi(0)disk(0)cdrom(159) \reactos\
Used memory 327284Kb
(ntoskrnl/mm/mminit.c:224) Start End Type
(ntoskrnl/mm/mminit.c:225) 0x80000000 - 0x80800000 Undefined region
(ntoskrnl/mm/mminit.c:228) 0x80800000 - 0x80E00000 FreeLDR Kernel
mapping region
(ntoskrnl/mm/mminit.c:231) 0x80E00000 - 0x80FE0000 PFN Database region
(ntoskrnl/mm/mminit.c:238) 0x80FE0000 - 0x873E0000 Non paged pool
region
(ntoskrnl/mm/mminit.c:241) 0x873E0000 - 0x8D7E0000 Paged pool region
(ARM³::INIT:340) System PTE count has been tuned to 22000 (90112000 bytes)
(ARM³::INIT:445) NP Pool has been tuned to: 10584064 bytes and 130072576
bytes
(ARM³::INIT:490) System PTE VA starts at: F3000000
(ARM³::INIT:491) NP Expansion VA begins at: F89EC000 and ends at: FFBE0000
(ARM³::INIT:507) PFN DB VA begins at: B0000000 and ends at: B01E0000
(ARM³::INIT:510) PFN DB PA PFN begins at: 1000
(ARM³::INIT:511) NP VA begins at: B01E0000 and ends at: B0BF8000
(ARM³::INIT:514) NP PA PFN begins at: 11e0
(ARM³::SYSPTE:341) System PTE space for 1 starting at: C03E27B4 and ending
at: C03FEF78
Assertion '(MmNumberOfSystemPtes - OldCount) <= 1000' failed at ARM³::INIT
line 652
Entered debugger on embedded INT3 at 0x0008:0x808bfcf6.
kdb:>
On Wed, Jun 24, 2009 at 10:43 PM, <tkreuzer(a)svn.reactos.org> wrote:
> - user32_winetest sysparams: before: 634 executed / 235 failures, after:
> 1093 executed, 11 failures
>
Very impressive.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and that is
an idea whose time has come." - Victor Hugo
Hi,
after thorough testing, 41446 appears to be the revision it would
make sense to branch 0.3.10 from (according to Victor Martinez).
Colin - please do a branch from 41446, and besides applying our usual
hacks, revert the most recent wininet sync since it breaks Download!
app. If you could do a prerelease iso for testing too, that would be
great.
WBR,
Aleksey Bragin.
sginsberg(a)svn.reactos.org wrote:
> Author: sginsberg
> Date: Wed Jun 17 16:44:05 2009
> New Revision: 41436
>
> [...] Because gcc is awesome we can then check for debug compilation with both #ifdef DBG and #if DBG (error free! yay gcc!), and so we have mixed usage all over the tree
MSVC behaves exactly the same way ;-P
I forgot to add to the commit message for r41520 that I lowered the
warning level of Visual C++ from -Wall to -W1. This will let us fix the
most serious compatibility issues first. Remember: set ROS_RBUILDFLAGS
to -dd -Mcmsc, and make --keep-going is your friend. Now go, and make
awesome things with this!
timo.kreuzer wrote:
>This is what I found:
[...]
So, essentially, what you found is that all versions you looked at,
did indeed define va_list if <stdarg.h> was included?
--
Mike
timo.kreuzer wrote:
>In recent ms crt headers, va_list is defined in crtdefs.h,
Also in vadefs.h (at least for VC8), which is then (obvious) included
by <stdarg.h>.
Do you have an example of an MS env. where including stdarg.h does not
define va_list?
--
Mike
On Tue, Jun 16, 2009 at 11:41 AM, <dchapyshev(a)svn.reactos.org> wrote:
> Author: dchapyshev
> Date: Tue Jun 16 19:41:29 2009
> New Revision: 41424
>
> URL: http://svn.reactos.org/svn/reactos?rev=41424&view=rev
> Log:
> - Add Symbol font from Wine
Thank you. This will save us a LOT of trouble later with Office applications.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
hyperion(a)svn.reactos.org wrote:
> Author: hyperion
> Date: Tue Jun 16 04:24:26 2009
> New Revision: 41421
>
> URL: http://svn.reactos.org/svn/reactos?rev=41421&view=rev
> Log:
> modified dll/win32/srclient/srclient_main.c
> What the hell, Arch Blackmann? <windef.h>, <winbase.h> and <winnls.h> are not meant to be included directly. Include <windows.h> instead
>
> modified drivers/video/font/ftfd/rosglue.c
> Move standard C includes before Windows includes, so the required types are defined beforehand
>
> modified include/crt/_mingw.h
> Re-add Visual C++ support
> va_list is not a built-in type, it does not belong in _mingw.h
> Do not include intrin.h (screw you, Arch)
> Removed definition of _USE_32BIT_TIME_T ("ROS HACK!")
>
> modified include/crt/conio.h
> modified include/crt/stdio.h
> modified include/crt/wchar.h
> Pull in va_list from stdarg.h
>
In recent ms crt headers, va_list is defined in crtdefs.h, so it's
defined by all headers. This might not fit ANSI C, but that's what ms
does. So for compatibility reasons we might want to do it the same way(?)
On Jun 13, 2009, at 9:25 AM, cgutman(a)svn.reactos.org wrote:
> Author: cgutman
> Date: Sat Jun 13 09:25:54 2009
> New Revision: 41399
> +UCHAR
> +EXPORT
> +NdisGeneratePartialCancelId(VOID)
> +{
> + static UCHAR CancelId = 0;
> +
> + CancelId++;
I don't think using static var for this purpose is a great idea.
WBR,
Aleksey Bragin.
aicommander wrote:
[...]
>The main problem with NDIS 5.1 drivers is the lack of S/G support in
HAL
> (PRO/100 and PRO/1000 XP drivers are affected by this).
Could the follwing info from public MSDN help? If so, it seems to be a
rather minor hack to make it work:
Scatter/gather DMA
Scatter/gather DMA is a shortcut method that sets up several
packet DMA transfers at once. If you are transferring a packet over the
network, for example, each part of the network stack adds its own
header (TCP, IP, Ethernet, and so forth). These headers are all
allocated from different places in memory. In this case, the
scatter/gather DMA saves time by issuing a batch request to the HAL to
map each header plus the data segment for access by the hardware.
Instead of having to call the packet DMA routines on each part of the
packet, this method calls each routine once, and lets the HAL be
responsible for mapping each one individually.
Note Scatter/gather capability does not mean that the device can
use the scatter/gather routines. Scatter/gather capability refers to a
flag in the device description that indicates that the device is able
to read or write from any area in memory, instead of just a certain
range.
--------
What I found to be the interesting (and easily hackable) part was "and
lets the HAL be responsible for mapping each one individually".
--
Mike
Ok, I've just read the actual code for NtSetInformationProcess (probably should have done that first)
It's right, what threw me was your r41390 commit which contained this :
+ PriorityClass.PriorityClass = PROCESS_PRIORITY_CLASS_HIGH;
+ PriorityClass.Foreground = FALSE;
+
+ /* Set priority for process */
+ if (!NT_SUCCESS(NtSetInformationProcess(ProcessInfo.ProcessHandle,
+ ProcessPriorityClass,
+ &PriorityClass,
+ sizeof(PROCESS_PRIORITY_CLASS))))
+ {
+ DPRINT1("Unable to set process priority for winlogon.exe\n");
+ }
I assumed from reading this that our NtSetInformationProcess was setting process priorities via #defines.
It turns out that the above is actually wrong. From pstypes.h :
#define PROCESS_PRIORITY_CLASS_HIGH 3
You were setting winlogon to have a priority of 3. Clearly not right ... heh.
Anyway, I see you've reverted it now. Problem solved.
I was just writing this follow up so you didn't start looking into NtSetInformationProcess and scratching your head wondering what my previous mail was about
Ged.
-----Original Message-----
From: Ged [mailto:gedmurphy@gmail.com]
Sent: 12 June 2009 18:48
To: 'ros-dev(a)reactos.org'
Subject: RE: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class
Hi
This change is wrong. ABOVE_NORMAL_PRIORITY_CLASS sets them to a process level of 10 which is too high.
Windows actually runs these at a level of 9 to ensure they get proc time before the regular NORMAL_PRIORITY_CLASS(8) processes but below the ABOVE_NORMAL_PRIORITY_CLASS(10) processes.
IIRC, you should be able to set the process directly using NtSetInformationProcess although our implementation doesn't seem to reflect this.
Is it our implementation or my memory which is wrong ?
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org
Sent: 12 June 2009 16:41
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class
Author: dchapyshev
Date: Fri Jun 12 19:41:26 2009
New Revision: 41389
URL: http://svn.reactos.org/svn/reactos?rev=41389&view=rev
Log:
- Start services.exe and lsass.exe with above normal priority class
Modified:
trunk/reactos/base/system/winlogon/winlogon.c
Modified: trunk/reactos/base/system/winlogon/winlogon.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/winlogon/winlo…
==============================================================================
--- trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] (original)
+++ trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] Fri Jun 12 19:41:26 2009
@@ -49,7 +49,7 @@
NULL,
NULL,
FALSE,
- DETACHED_PROCESS,
+ DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&StartupInfo,
@@ -97,7 +97,7 @@
NULL,
NULL,
FALSE,
- DETACHED_PROCESS,
+ DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&StartupInfo,
Hi
This change is wrong. ABOVE_NORMAL_PRIORITY_CLASS sets them to a process level of 10 which is too high.
Windows actually runs these at a level of 9 to ensure they get proc time before the regular NORMAL_PRIORITY_CLASS(8) processes but below the ABOVE_NORMAL_PRIORITY_CLASS(10) processes.
IIRC, you should be able to set the process directly using NtSetInformationProcess although our implementation doesn't seem to reflect this.
Is it our implementation or my memory which is wrong ?
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dchapyshev(a)svn.reactos.org
Sent: 12 June 2009 16:41
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dchapyshev] 41389: - Start services.exe and lsass.exe with above normal priority class
Author: dchapyshev
Date: Fri Jun 12 19:41:26 2009
New Revision: 41389
URL: http://svn.reactos.org/svn/reactos?rev=41389&view=rev
Log:
- Start services.exe and lsass.exe with above normal priority class
Modified:
trunk/reactos/base/system/winlogon/winlogon.c
Modified: trunk/reactos/base/system/winlogon/winlogon.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/winlogon/winlo…
==============================================================================
--- trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] (original)
+++ trunk/reactos/base/system/winlogon/winlogon.c [iso-8859-1] Fri Jun 12 19:41:26 2009
@@ -49,7 +49,7 @@
NULL,
NULL,
FALSE,
- DETACHED_PROCESS,
+ DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&StartupInfo,
@@ -97,7 +97,7 @@
NULL,
NULL,
FALSE,
- DETACHED_PROCESS,
+ DETACHED_PROCESS | ABOVE_NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&StartupInfo,
Hi,
as we earlier discussed, there is an idea to make 0.3.10 a "hardware-
compatibility" release.
There is a full list of 0.3.10 milestones bugs linked from our
roadmap page, but here are some possible directions for work:
- USB support for keyboard and mouse devices. Right now, it needs
fixing the rare crash during booting (bug is bugzilled, comment
explaining how to solve the problem is attached, some investigation
remains), and more testing on real hardware.
- Uniata support: it solves many problems at once, such as a stupid
8Gb limit which is a nonsense for a 2009-year operating system, and
Serial ATA support, which greatly enhances possible ReactOS usability
(along with the first item of this list). I use it in my builds
everyday for more than a month, it works very good. Problems:
VirtualBox CDROM support (it doesn't recognize it), on my
realhardware it also experiences similar problems. Bug is also
bugzilled, a lot of debug logs attached, so everyone can participate.
- Common NICs support: Cameron is doing great work, testers too.
There are some outstanding problems, which you can see from http://
www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards
- Sound support: Johannes knows best, but getting any progress with
sound by 0.3.10 release date is greatly appreciated.
- Videocards support: Olaf performs some tesitng and bugreporting.
Third party drivers support is rather weak, http://www.reactos.org/
wiki/index.php/Supported_Hardware/Video_cards , and usually is
limited by VMWare's video driver which is being one of the most
supported through the ReactOS development history.
Besides of that, Olaf is organizing the Golden Apps testing, so that
we won't discover regressions occasionally or by the time the release
is branched and everyone is awaiting, but instead that's going to
happen on a periodical basis, and he's going to manage this process
with help of our fellow testers.
Target 0.3.10 release date is month from now on - that means,
somewhere in the end of May. Certainly, if our goals aren't met, the
release is going to be rescheduled and that's it, but, I'd like to
ask to concentrate on the above problems first. They are hard to
solve when every problem is being approached by one person, but with
a common effort they aren't going to be a problem.
Any new developers - welcome! There are very definite goals, enough
of information, so please feel free to join and help.
With the best regards,
Aleksey Bragin.
As for Videocards, it seems that our situation is not as bad as it was
perceived before. Its not perfect, of course.
- currently i can name at least 3 cards working on my ReactOS PC with native
XP drivers: ATI Rage II+, Matrox G100 and Matrox G400. With considerable
cerainty i can say that all Matrox models inbetween or bit newer than
afforementioned model range will also be working, as they are using same
driver package;
- all vesa 2.0 videocards i tested are working correctly with our VESA
driver. Only single cases have issues here;
We still have a number of bugs in this area, for your consideration:
- lack of VESA 1.2 support: this locks up older PCI cards, like whole S3
family (up to savage) to VGA driver. Only workaround is to use native XP
drivers. It succeeded with S3 Trio 64, but uncovered another bug listed
belo; (bug no.4447)
- if XP video driver is installed (by slipstreaming into bootcd) on
installation with VGA driver selected in 1st stage, even though XP driver is
loaded, the system will be locked to VGA mode (640x480x4bpp unchangeable).
This one is not yet submitted as it needs to be confirmed by other tester
first;
- VGA driver, if picked in 1st stage, jumps back to VESA on 3rd stage boot.
This can be rigged away by replacing VESA driver with vga driver files,
leaving the filenames of the former (bug no.
- Some Windows VGA drivers will cause ASSERT in Videoprt. In many cases this
ASSERT may be cont-ed without any visible side-effect, yet it requires more
attention (bug no.4354);
- our opengl setup requires only specific opengl setup (bug no. 4574);
- Matrox G400 opengl ICD is not cooperating well with our opengl32.dll
(fails when DrvDescribePixelFormat is called from the icd), requires more
attention and a way to instert breakpoint within ReactOS to an dll that has
not been loaded yet, namely a working debugger like Olly);
I am also preparing to create a support page for I/O controllers, as soon as
i get some components for a few entries.
As of r41374, Visual C++ suppport in rbuild is almost fully functional
(PCH and full dependencies - i.e. rbuild -df - won't work yet. Also, the
Microsoft linker is not supported yet). All I need now is people working
to make sources compile with it. How to: add option -Mcmsc to variable
ROS_RBUILDFLAGS:
set ROS_RBUILDFLAGS=%ROS_RBUILDFLAGS% -Mcmsc
and build modules! make --keep-going will be very useful for the time
being. Now start fixing shit, for the love of god! go go go!
So you want to make Visual C++ building support a reality. Good. Do you
have Visual Studio, Visual C++ Express or any flavor of the DDK? Do you
have trunk checked out and updated? Even better. Do the following from a
RosBE prompt:
* del makefile.auto
* set ROS_RBUILDFLAGS=-Mmicrosoft
* make rbuild
and reply to this message with:
* what version of Visual Studio, Visual C++ Express or the DDK you
installed
* the output of the "[RBUILD] makefile.auto" phase
To clean up and resume building as usual:
* del makefile.auto
* set ROS_RBUILDFLAGS=
Thank you
> * what version of Visual Studio, Visual C++ Express or the DDK you
> installed
Microsoft Visual Studio 2005 Version 8.0.50727.867 (vsvista.050727-8600)
> * the output of the "[RBUILD] makefile.auto" phase
[RBUILD] makefile.auto
Reading build files...done
Detecting compiler...detected (cl 14.0.50727.762)
Detecting binutils...detected (link 8.0.50727.762)
Detecting netwide assembler...detected (nasm 2.05.01)
Detecting compiler pre-compiled header support...disabled
Processing modules...done
Creating directories...done
Generating test support code...done
Generating compilation unit support code...done
Generating syssetup.inf...done
Generating proxy makefiles...done
Checking automatic dependencies...done
Regards,
Victor.
_________________________________________________________________
Descubre todas las formas en que puedes estar en contacto con amigos y familiares.
http://www.microsoft.com/windows/windowslive/default.aspx
On Sun, Jun 7, 2009 at 7:39 PM, <hyperion(a)svn.reactos.org> wrote:
> +#include "../../pch.h"
This is really minor but can you fix it by changing the -I path?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
On Sun, Jun 7, 2009 at 7:33 PM, <hyperion(a)svn.reactos.org> wrote:
> +#include "../../pch.h"
Ditto for here.
> +
> +// TODO? attempt to support Microsoft tools on non-Windows?
> +#if !defined(WIN32)
> +
> +bool
> +MingwBackend::DetectMicrosoftCompiler ( std::string& )
> +{
> + return false;
> +}
There are some crazy people that run cl under Wine. I know older
versions such as the vctoolkit worked. I'm not sure about more recent
revs. I'm happy to try to make time to look in to this at some point.
It would be nice for us Linux and OS X users to be able to verify
things from time to time with msvc without needing a fullblown vm.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi all!
I noticed we still have drawing issues even after fixing some gdi
code. Well, I guess we need to look at the main windowing side of the
house now. I guess, based on a stable release we can sync up wine and
patch by hand the forked code too. I know of some Delphi issues that
could use a good non static update. Bulk of our user code is from wine
and that includes the window positioning bug everyone has had a crack
at as well. I notices that most of the syncs in comdlg/controls depend
on user code updates. If Richedit breaks windowing, it could be
related to user32/win32k code not updated or based on behavior that is
wrong. Syncing and updating forked code is not fun, with both, one
needs to take into account local fixes. When you find them, mark them
like "REACTOS HACK" or "REACTOS ONLY" or "REACTOS ????" what ever.
Reading the change logs for each file should help with determining
local patches that have been applied and need to be taken into account
as well. If you have a bug report, please mark it as WINE SYNC or WINE
UPDATE, something to let us know, it's a wine sync of some kind. We
have a file in our media doc directory that holds the sync/fork
information, please include it with your updates.
Thanks,
James
Ref: README.WINE:
User32 -
reactos/dll/win32/user32/controls/button.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/combo.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/edit.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/icontitle.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/listbox.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/scrollbar.c # Forked
reactos/dll/win32/user32/controls/static.c # Synced at 20071024
reactos/dll/win32/user32/misc/dde.c # Synced to wine
1.1.17 (dde_misc.c)
reactos/dll/win32/user32/misc/ddeclient.c # Synced to wine 1.1.17
reactos/dll/win32/user32/misc/ddeserver.c # Synced to wine 1.1.17
reactos/dll/win32/user32/misc/exticon.c # Last sync date unknown
reactos/dll/win32/user32/misc/resources.c # Forked?
reactos/dll/win32/user32/misc/winhelp.c # Last sync date unknown
reactos/dll/win32/user32/misc/wsprintf.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/windows/defwnd.c # Forked
reactos/dll/win32/user32/windows/draw.c # Forked at
Wine-20020904 (uitools.c)
reactos/dll/win32/user32/windows/mdi.c # Synced at 20060703
reactos/dll/win32/user32/windows/menu.c # Forked
reactos/dll/win32/user32/windows/messagebox.c # Forked
reactos/dll/win32/user32/windows/rect.c # Forked (uitools.c)
reactos/dll/win32/user32/windows/text.c # Forked (lstr.c)
reactos/dll/win32/user32/windows/winpos.c # Forked
This looks like ultra-hax. Can you explain why this should be correct?
It would mean DrvSetPixelFormat would be passed a SURFACE rather than a
SURFOBJ.
jimtabor(a)svn.reactos.org schrieb:
> Author: jimtabor
> Date: Tue Jun 2 10:50:36 2009
> New Revision: 41250
>
> URL: http://svn.reactos.org/svn/reactos?rev=41250&view=rev
> Log:
> - Hax-implement NtGdiSetPixelFormat and add a support function UserGethWnd with some code cleanup.
>
> Modified:
> [...]
> + /*
> + Based on some rules! InfoDC to DC or, based on wiki information!
> + All pointers, it's a "must be!", (CONTAINING_RECORD +10h = SURFOBJ), the
> + pointer will start at SURFOBJ of the SURFACE structure.
> + */
> + pso = (SURFOBJ *)pdc->dclevel.pSurface;
> + if (!pso) pso = pdc->pSurfInfo;
> + if (!pso) pso = ppdev->pSurface;
> + }
> +
> + if (ppdev->flFlags & PDEV_META_DEVICE)
> + {
> + UNIMPLEMENTED;
> + goto Exit;
> + }
> +
> + if (ppdev->DriverFunctions.SetPixelFormat)
> + {
> + Ret = ppdev->DriverFunctions.SetPixelFormat(
> + pso,
> + ipfd,
> + hWnd);
> + }
>
I find the defination of CHECKPOINT
#define CHECKPOINT do { DbgPrint("%s:%d\n",__FILE__,__LINE__); ExAllocatePool(NonPagedPool,0); } while(0);
I don't know why alloc memory with 0 byte
I must say that I protest to all the recent I/O changes, and in my
opinion, they are all wrong and badly researched, and have hacked what
was once good code.
Best regards,
Alex Ionescu
On Wed, Jun 3, 2009 at 2:48 AM, <mjmartin(a)svn.reactos.org> wrote:
> Author: mjmartin
> Date: Wed Jun 3 13:48:33 2009
> New Revision: 41269
>
> URL: http://svn.reactos.org/svn/reactos?rev=41269&view=rev
> Log:
> - IopCreateDriver: Change MajorFunction routines back to internal function IopInvalidDeviceRequest for ones that were set to NULL in the Drivers DriverEntry. Windows does it and so shall we.
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/driver.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/driver.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/driver.c…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] Wed Jun 3 13:48:33 2009
> @@ -1302,7 +1302,7 @@
> RtlZeroMemory(DriverObject, ObjectSize);
> DriverObject->Type = IO_TYPE_DRIVER;
> DriverObject->Size = sizeof(DRIVER_OBJECT);
> - DriverObject->Flags = DRVO_BUILTIN_DRIVER;
> + DriverObject->Flags = DRVO_LEGACY_DRIVER;//DRVO_BUILTIN_DRIVER;
> DriverObject->DriverExtension = (PDRIVER_EXTENSION)(DriverObject + 1);
> DriverObject->DriverExtension->DriverObject = DriverObject;
> DriverObject->DriverInit = InitializationFunction;
> @@ -1398,6 +1398,14 @@
> {
> /* Returns to caller the object */
> *pDriverObject = DriverObject;
> + }
> +
> + /* Loop all Major Functions */
> + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
> + {
> + /* Set each function that was set to NULL to internal routine */
> + if (!DriverObject->MajorFunction[i])
> + DriverObject->MajorFunction[i] = IopInvalidDeviceRequest;
> }
>
> /* Return the Status */
>
>
There's nothing ugly about this -- this is exactly what the field is for.
Best regards,
Alex Ionescu
On Sat, May 30, 2009 at 4:07 PM, <cgutman(a)svn.reactos.org> wrote:
> Author: cgutman
> Date: Sun May 31 03:07:13 2009
> New Revision: 41213
>
> URL: http://svn.reactos.org/svn/reactos?rev=41213&view=rev
> Log:
> - Export and hackplement NdisSetTimerEx
> - Implementation is #ifed out currently but I may enable it later
> - Hopefully somebody can think of a better way to do it than the current code
>
> Modified:
> trunk/reactos/drivers/network/ndis/ndis.def
> trunk/reactos/drivers/network/ndis/ndis/time.c
>
> Modified: trunk/reactos/drivers/network/ndis/ndis.def
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis.…
> ==============================================================================
> --- trunk/reactos/drivers/network/ndis/ndis.def [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis.def [iso-8859-1] Sun May 31 03:07:13 2009
> @@ -257,6 +257,7 @@
> NdisSetPacketPoolProtocolId@8
> ;NdisSetProtocolFilter ?
> NdisSetTimer@8
> +NdisSetTimerEx@12
> NdisSetupDmaTransfer@24
> NdisSystemProcessorCount@0
> NdisTerminateWrapper@8
>
> Modified: trunk/reactos/drivers/network/ndis/ndis/time.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis/…
> ==============================================================================
> --- trunk/reactos/drivers/network/ndis/ndis/time.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis/time.c [iso-8859-1] Sun May 31 03:07:13 2009
> @@ -243,5 +243,26 @@
> KeSetTimer (&Timer->Timer, Timeout, &Timer->Dpc);
> }
>
> +VOID
> +EXPORT
> +NdisSetTimerEx(
> + IN PNDIS_TIMER Timer,
> + IN UINT MillisecondsToDelay,
> + IN PVOID FunctionContext)
> +{
> +#if 0
> + /* FIXME: I'm not sure how to this in a nice way
> + * We can't store the function context anywhere in NDIS_TIMER
> + * so I'm forced to do this
> + */
> +
> + Timer->Dpc.DeferredContext = FunctionContext;
> +
> + NdisSetTimer(Timer, MillisecondsToDelay);
> +#else
> + UNIMPLEMENTED
> +#endif
> +}
> +
> /* EOF */
>
>
>
Hi
I download a very early edtion of reactos(0.0.21), I think it would be
easy to understand for me. I disable the NDEBUG macro, so I can catch the
debug info. By default, I use the /DEBUGPORT=SCREEN, and the log info is
printed on the screen. Then I changed to /DEBUGPORT=BOCHS, but there is no
any info on the bochs console.
Could you tell me how to catch the log on the bochs?
Fan Zhang
Ok before you go on in this area, I am currently working on a complete
rewrite of sysparams stuff. It should hopefully be ready this week and
should fix almost all winetests and additional tests in this area.
Regards,
Timo
dchapyshev(a)svn.reactos.org schrieb:
> Author: dchapyshev
> Date: Mon May 25 17:08:57 2009
> New Revision: 41115
>
> URL: http://svn.reactos.org/svn/reactos?rev=41115&view=rev
> Log:
> - Stubimplement SPI_GETFONTSMOOTHINGTYPE/SPI_SETFONTSMOOTHINGTYPE
>
> Modified:
> trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c
>
> Modified: trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt…
> ==============================================================================
> --- trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c [iso-8859-1] (original)
> +++ trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c [iso-8859-1] Mon May 25 17:08:57 2009
> @@ -699,6 +699,22 @@
> {
> ASSERT(pvParam);
> *((BOOL*)pvParam) = IntIsFontRenderingEnabled();
> + break;
> + }
> + case SPI_SETFONTSMOOTHINGTYPE:
> + {
> + if (*((UINT*)pvParam) == FE_FONTSMOOTHINGCLEARTYPE)
> + {
> + DPRINT1("ReactOS does not support ClearType smoothing but it is returned TRUE\n");
> + }
> + bChanged = TRUE;
> + break;
> + }
> + case SPI_GETFONTSMOOTHINGTYPE:
> + {
> + /* We do not support ClearType. Only standard smoothing */
> + DPRINT1("ReactOS does not support ClearType smoothing. Returned FE_FONTSMOOTHINGSTANDARD\n");
> + *((UINT*)pvParam) = FE_FONTSMOOTHINGSTANDARD;
> break;
> }
> case SPI_GETICONTITLELOGFONT:
>
>
>
Hi..
I have had an idea which i want to share with you, so we can discuss if it is interesting or stupid enough.
Right now we have a Winetests comparator called TestMan thanks to the efforts of Colin and Lone_Rifle. This script compares the Winetest results of different revisions. It is really helpful to find regressions(Thanks Lone_rifle to be supervising them from time to time :) ).
My idea is about creating/adding a new script which compares the winetest results of a ReactOS revision vs the result of the WineHQ winetests.
Of course just in those functions/modules that we have full-synced with Wine.
Why?
Lets imagine that our Wininit:FTP functions are synced(as they are).That means that the code of those functions are the same in Wine and in ReactOS. That means that Bugs present in that code will be present in ReactOS too.These could be called the Expected bugs.ReactOS should fail in these tests since Wine functions are bugged: call them Expected Fails.
But sometimes ReactOS is showing more fails than the Expected Fails( in synced code).Why?
Well, these synced functions use other deeper functions which arent synced with Wine and which is own ReactOS code.And, of course,which can have Bugs.If these deeper functions arent working properlly then affects the synced functions which uses them and then you will see extra tests failing.
Lets give a small example.
Wininit:FTP is synced with Wine.
WineHQ reports 6 failures : http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_w…
ReactOS latest rev reports 19 failures: http://79.99.5.181/testman/detail.php?id=141321
These 13 extra failures arent expected.We expect just 6 Expected Fails (which seems to be related with Bugs in Wine code), so this 13 extra failures are related with deeper functions (which are ReactOS own code).
So the New Script would check the failures in WineHQ and in ReactOS rev and warn when the number of failures is higher than the number of Expected failures,showing also the differences, so the New Script can easily point our Devs towards ReactOS bugs, helping he "hunting" giving "clues" to them.
If my reasoning is wrong,or i am missing something,please tell me. :)
How much useful would be this Script?Is it interesting enough for Developing purposes?or Is it a waste of time/efforts?
Note: The ie is Bugzilled.It´s curious,since doing a small Timing trick you can have the 6 Expected Fails instead the 19 failures.
http://www.reactos.org/bugzilla/show_bug.cgi?id=4533
Vicmarcal
_________________________________________________________________
¡Acelera con la Fórmula 1! Juega y demuestra lo que sabes con MSN Deportes
http://msn.es.predictorpro.com/grand-prix/overview.aspx?season=8
Well mate, pity to hear that!
As you well know, one cannot simply leave this project! So everyone`s gonna
be glad to see you lurking around!
Best regards
Sorry for not replying to e-mails about this -- I was on vacation on a cruise.
When I'm back to Montreal I'll write a driver to test if this is
correct or not -- but definitely this is better.
Best regards,
Alex Ionescu
On Mon, May 25, 2009 at 1:17 AM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Mon May 25 03:17:48 2009
> New Revision: 41106
>
> URL: http://svn.reactos.org/svn/reactos?rev=41106&view=rev
> Log:
> MmGrowKernelStack: go back to the ASSERT and add a fixed check
>
> Modified:
> trunk/reactos/ntoskrnl/mm/procsup.c
>
> Modified: trunk/reactos/ntoskrnl/mm/procsup.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/procsup.c?rev=…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/procsup.c [iso-8859-1] Mon May 25 03:17:48 2009
> @@ -258,11 +258,15 @@
> {
> PETHREAD Thread = PsGetCurrentThread();
>
> - /* Make sure we have reserved space for our grow */
> - if (((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit) >
> - (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE))
> - {
> - return STATUS_NO_MEMORY;
> + /* Make sure the stack did not overflow */
> + ASSERT(((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit) <=
> + (KERNEL_LARGE_STACK_SIZE + PAGE_SIZE));
> +
> + /* Check if we have reserved space for our grow */
> + if ((PCHAR)Thread->Tcb.StackBase - (PCHAR)Thread->Tcb.StackLimit +
> + KERNEL_STACK_SIZE > KERNEL_LARGE_STACK_SIZE)
> + {
> + return STATUS_STACK_OVERFLOW;
> }
>
> /*
>
>
May I ask, why not use simple C for this?:
DriverBlock->DriverObject->MajorFunction = MajorFunctions;
Or if that doesn't work, use a casting trick...
Best regards,
Alex Ionescu
On Sun, May 24, 2009 at 2:49 AM, <cgutman(a)svn.reactos.org> wrote:
> Author: cgutman
> Date: Sun May 24 04:49:02 2009
> New Revision: 41090
>
> URL: http://svn.reactos.org/svn/reactos?rev=41090&view=rev
> Log:
> - MajorFunction has IRP_MJ_MAXIMUM_FUNCTION positions
> - Sorry for so many commits on the same function
>
> Modified:
> trunk/reactos/drivers/network/ndis/ndis/miniport.c
>
> Modified: trunk/reactos/drivers/network/ndis/ndis/miniport.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis/…
> ==============================================================================
> --- trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis/miniport.c [iso-8859-1] Sun May 24 04:49:02 2009
> @@ -2788,7 +2788,7 @@
> return NDIS_STATUS_RESOURCES;
> }
>
> - for (i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++)
> + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
> DriverBlock->DriverObject->MajorFunction[i] = MajorFunctions[i];
>
> DriverBlock->DriverObject->MajorFunction[IRP_MJ_PNP] = NdisIDispatchPnp;
>
>
What is the reason we don't sync wine's secur32?
Thanks,
Timo
cwittich(a)svn.reactos.org schrieb:
> Author: cwittich
> Date: Sun May 24 13:40:15 2009
> New Revision: 41096
>
> URL: http://svn.reactos.org/svn/reactos?rev=41096&view=rev
> Log:
> fix secur32 main winetest crash by returning 0 packages in EmumSecurityPackagesA/W
>
> Modified:
> trunk/reactos/dll/win32/secur32/sspi.c
>
>
Hi,
This mail is a little bit late as I didn't find time to write it earlier.
Basically, I've decided that I do not want to continue working on
ReactOS. I just don't find it "fun" or interesting to do any more.
I spent months trying to get my head around Kernel Streaming and its
associated components, how they fit together let alone how they actually
function. And really, it's not enjoyable. I don't fully understand
Windows kernel-mode coding, and coding the sound system really isn't as
straightforward a task as I had originally anticipated. It has become
more of a chore over time.
Considering I made the switch from Windows to Linux around 2005 and have
rarely actually needed to use Windows at home since then, there doesn't
seem to be any benefit for me to put my time into working on ReactOS.
Also I never really seemed to get very far with sound... I see
Janderwald has taken up the challenge on this and is making good
progress on it.
I had been considering leaving a few months ago, but stuck around for
our gathering in Brussels, which was great (aside from the restaurant
which seemed like it was going to cook its customers, and the
overly-smiley waiter who didn't fully explain what "special sauce"
contained...) To be honest I think putting the hybrid CD together for
that to be my best and also most hacky achievement for ReactOS. Starflow
produced all the fliers/badges/etc. and I think altogether, FOSDEM was a
success. And I hope it sparked interest for other people to join the
project.
I intend on working on some of my own projects from this point on
(possibly audio related still...)
All the best for the future,
Andrew Greenwood
I have the code to complete this functionality locally, I just haven't committed it yet as it's not tested.
Thanks for the conflict :-P
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tkreuzer(a)svn.reactos.org
Sent: 22 May 2009 23:18
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [tkreuzer] 41046: #if out an unused static funtion. Don't know if it's still useful. Ged?
Author: tkreuzer
Date: Sat May 23 02:17:55 2009
New Revision: 41046
URL: http://svn.reactos.org/svn/reactos?rev=41046&view=rev
Log:
#if out an unused static funtion. Don't know if it's still useful. Ged?
Modified:
branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c
Modified: branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c
URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/base/…
==============================================================================
--- branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c [iso-8859-1] (original)
+++ branches/ros-amd64-bringup/reactos/base/applications/mscutils/servman/propsheet_depends.c [iso-8859-1] Sat May 23 02:17:55 2009
@@ -50,6 +50,7 @@
return TreeView_InsertItem(hTreeView, &tvins);
}
+#if 0 // FIXME: What is this good for?
static VOID
AddServiceDependency(PSERVICEPROPSHEET dlgInfo,
HWND hTreeView,
@@ -123,6 +124,7 @@
}
}
+#endif
static VOID
AddServiceDependent(HWND hTreeView,
I hope you asked James and Timo, who may have uncommitted patches to
this file (which would fail to apply now).
WBR,
Aleksey Bragin.
On May 22, 2009, at 4:50 PM, dchapyshev(a)svn.reactos.org wrote:
> Author: dchapyshev
> Date: Fri May 22 16:50:31 2009
> New Revision: 41042
>
> URL: http://svn.reactos.org/svn/reactos?rev=41042&view=rev
> Log:
> - Formatting fix. No code change
>
> Modified:
> trunk/reactos/subsystems/win32/win32k/ntuser/hook.c
>
On Thu, May 14, 2009 at 2:52 PM, KJK::Hyperion <hackbunny(a)reactos.org> wrote:
> Ged wrote:
>> Another unix like addition?
>> Do we really need this and the previous telnet server in our source?
>
> to be fair, Windows does provide a command line TFTP client/server. So
> far, I've only seen it used for malware spreading, but it's there and we
> should provide one too
Where I work we use dhcpd/tftp and PXEboot on both Linux and Windows
to do automagical deployment services. The end goal with all of this
is a ReactOS deployment system from a single image that can provision
ReactOS thinkclients/diskless workstations without the need of a Linux
or Windows host.
Pushing out a freeldr or grub+freeldr or even pxelinux+grub+freeldr
image with a blob containing a ROS ramdisk should be pretty simple
using isc-dhcpd/tftp on Linux but I'm more interested in the
infrastructure side of things right now. Currently the dhcpd with PXE
support is the only part we are really missing. We COULD do it from
Linux or Windows right now, but I want to get all the infrastructure
in place where we don't need any other OS.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Thank you for your answer. But I'm still perplexd.
pushl %eax //at that time ,%eax=0? so BootMain will receive NULL parameter?
call _BootMain
--- On Wed, 5/20/09, pay7n(a)o2.pl <pay7n(a)o2.pl> wrote:
> From: pay7n(a)o2.pl <pay7n(a)o2.pl>
> Subject: Re: [ros-dev] runtime time function question in freeldr
> To: "ReactOS Development List" <ros-dev(a)reactos.org>
> Date: Wednesday, May 20, 2009, 3:18 AM
> This is not an Intel syntax.
> Operands in memory operations have inverted order:
>
> mov src, dest
>
> not
>
> mov dest, src
>
> thus eax == 0
>
>
> Zhang Fan pisze:
> > Hi everybody,
> > I'm a newbie of ReactOS, and I've just looked a piece
> of code in freeldr module. I found some runtime function
> such as strstr(). I want to know if the run time lib should
> be initialized, and where the initialized code.
> > Another question is that a piece of code in arch.S
> >
> >
> > EXTERN(RealEntryPoint)
> >
> > //....
> > .code32
> >
> > /* Zero BootDrive and BootPartition
> */
> > xorl %eax,%eax
> > movl
> %eax,(_BootDrive)
> > movl
> %eax,(_BootPartition)
> >
> > /* Store the boot drive */
> > movb
> %dl,(_BootDrive)
> >
> > /* Store the boot partition */
> > movb
> %dh,(_BootPartition)
> >
> > /* GO! */
> > pushl %eax
> > call _BootMain
> >
> > At there, I think %eax should equal zero, and BootMain
> will call CmdLineParse(),and CmdLineParse will call
> strstr(). So it cause strstr will receive a NULL parameter.
> Is it right?
> >
> > Thank you.
> >
> > Fan Zhang
> >
> >
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hi everybody,
I'm a newbie of ReactOS, and I've just looked a piece of code in freeldr module. I found some runtime function such as strstr(). I want to know if the run time lib should be initialized, and where the initialized code.
Another question is that a piece of code in arch.S
EXTERN(RealEntryPoint)
//....
.code32
/* Zero BootDrive and BootPartition */
xorl %eax,%eax
movl %eax,(_BootDrive)
movl %eax,(_BootPartition)
/* Store the boot drive */
movb %dl,(_BootDrive)
/* Store the boot partition */
movb %dh,(_BootPartition)
/* GO! */
pushl %eax
call _BootMain
At there, I think %eax should equal zero, and BootMain will call CmdLineParse(),and CmdLineParse will call strstr(). So it cause strstr will receive a NULL parameter. Is it right?
Thank you.
Fan Zhang
Hello mailing list folks!
While Xiaoming wouldn't be able to have commit access, would he be able to contribute in other ways not related to coding,
i.e., hardware or software testing? Just curious.
Mr. Ionescu, I probably would have tried to tell Xiaoming what I know about the rules, too, even though I'm not a developer.
Actually, the FAQ is pretty clear in regards to ReactOS only using clean-room reverse engineering.
http://www.reactos.org/en/about_userfaq.html. I would have just referred him to this, if you or another developer hadn't jumped in
to give a more precise answer. I usually leave it up to the devs to answer questions, but I try to answer questions if I can when
no developer is at hand at the moment. I hope that doesn't mean I have a drug problem. :)
To be honest, I was pretty confused myself about who could do what if they had seen Windows source code beforehand. I know the
current position is that seeing source code != no ReactOS programming for you, but then again there was the whole debate a few years
back about whether the devs at the top had seen any Windows source code and I'm still not sure how that got resolved. I had
alternately heard that people who had seen source code couldn't contribute, or if they had they could only code stuff whose Windows
equivalents they hadn't seen the source code to, so it's not something that was just made up. I'm not trying to restart old flame wars,
but the fact is that the policy regarding Windows source code hasn't always been so clear, which may have left some people (myself
included) confused. While I personally wouldn't have replied assuming the same level of authority as a developer, I don't think us
ordinary folks should be blamed if we've gotten a little confused about this througout the course of the past few years.
I don't mean to start off here on a bad note, but I get irritated because on the forums someone asks a simple question, someone answers,
the devs get angry because they feel someone overstepped their authority, even thought the devs tend to give a terse answer with no
explanation. The newbie scared of asking anything else about the project because folks get so angry with one another, and figures it's
not worth the trouble of getting involved.
By the way, if the formatting here looks like it was written by a crackhead, it's because this is my first time posting on the mailing
list. (I'm more active on the forums.) Then again, my hometown inspired The Wire, so who knows. :P
-Joshua Bailey
Hi guys:
I have read the linux kernel code and part of the leaked winnt source
code,and i want to join the developing of ReactOS kernel,how can i join??
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
Isn't that actually the same?
It also ignores the number of full descriptors, which I guess is wrong.
And it looks like the whole parsing code is broken. It ignores the
number of partial descriptors and does FullList++
Timo
janderwald(a)svn.reactos.org schrieb:
> Author: janderwald
> Date: Sat Apr 25 16:05:08 2009
> New Revision: 40694
>
> URL: http://svn.reactos.org/svn/reactos?rev=40694&view=rev
> Log:
> - Fix allocation of CM_RESOURCE_LIST
> - Might fix bug 4354
> See issue #4354 for more details.
>
> Modified:
> trunk/reactos/drivers/video/videoprt/dispatch.c
>
> Modified: trunk/reactos/drivers/video/videoprt/dispatch.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/video/videoprt/dis…
> ==============================================================================
> --- trunk/reactos/drivers/video/videoprt/dispatch.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/video/videoprt/dispatch.c [iso-8859-1] Sat Apr 25 16:05:08 2009
> @@ -340,9 +340,11 @@
>
> /* Save the resource list */
> ResourceCount = AllocatedResources->List[0].PartialResourceList.Count;
> - ResourceListSize =
> - FIELD_OFFSET(CM_RESOURCE_LIST, List[0].PartialResourceList.
> - PartialDescriptors[ResourceCount]);
> + ResourceListSize = sizeof(CM_RESOURCE_LIST);
> +
> + if (ResourceCount > 1)
> + ResourceListSize += (ResourceCount-1) * sizeof(CM_PARTIAL_RESOURCE_DESCRIPTOR);
> +
> DeviceExtension->AllocatedResources = ExAllocatePool(PagedPool, ResourceListSize);
> if (DeviceExtension->AllocatedResources == NULL)
> {
>
>
>
I feel that some things really need to be clearly explained, regarding apps
being use to test releases with.
At the moment, despite numerous attempts, i failed to find who (if anyone)
is responsible for compiling and maintaining the list of apps used for
release version testing. Especially, the non-downloader stuff section is
basically changing completely with every release, making those tests
virtually pointless, if we cant keep any consistency. On the other hand,
looks like no one is responsible for maintaining Downloader app list.
Without such responsibilites set, we are slipping into disorganisation,
which is both confusing and uproductive. Clear policies should be set and
observed in this matter, taking care of such basic thing as
adding/linking/opening a bug report for an app that failed in release Test.
I feel that testers have more productive things to do, than cleaning
up/sorting test entries, incorrectly made up by first timers.
Sorry if anyone feels this post to sound harsh, but its still really gentle
and kind, compared to obscenities, curses and swears others have to put up,
when i vent out after seeing the current state of Release testing wiki.
HI!
I was wondering if you people were interested in a new ISO/QUEMU/VMWARE
download mirror, I got space and on my server and I would like to help this
wonder full project.
If the service I'm offering you for free please answer back with the
information for starting "mirroring"
Here's my server's information:
Conection speed: VLAN on 100Mbits
Mirroring protocol: HTTP
Space reserved for ReactOS: 7GB,
Bandwith: Unlimited Bandwith
Waiting your answer,
Jorge Guerra
Kernel Error Administrator
Will Rogers <http://www.brainyquote.com/quotes/authors/w/will_rogers.html>
- "I don't make jokes. I just watch the government and report the
facts."
Hi,
by today most of the bugs which were having 0.3.9 as a milestone are
fixed - including fixing 4-months old bug with richedit control,
properly trimming DLL names during PE loading so that apps now can
find their DLLs (previously that failed in some cases), newest
downloader problem introduced yesterday and fixed today (not to speak
about yesterday's fixes too!).
This is a very good example of team collaboration, team effort aimed
at a narrow set of problems. It worked very well, and I think we
would utilise such bugfixing sessions in future too.
Branching date is now set to tomorrow, 17th of April, 2009 and is not
going to be changed anymore. As soon as the 0.3.9 branch is created,
feature freeze is considered to be finished.
After the release is branched, usual testing will be conducted,
actual packages built and released as usual.
Thank you for your efforts and for being patient with regards to the
feature freeze.
WBR,
Aleksey Bragin.
Dmitry! Please! It's only a few hours left till we create a branch
and normal development resumes!
WBR,
Aleksey Bragin.
On Apr 18, 2009, at 1:01 AM, dgorbachev(a)svn.reactos.org wrote:
> Author: dgorbachev
> Date: Sat Apr 18 01:01:56 2009
> New Revision: 40565
>
> URL: http://svn.reactos.org/svn/reactos?rev=40565&view=rev
> Log:
> Begin Japanese translation of USetup
>
> Added:
> trunk/reactos/media/vgafonts/932-8x8.bin (with props)
> Modified:
> trunk/reactos/base/setup/usetup/lang/ja-JP.h
> trunk/reactos/base/setup/usetup/muifonts.h
> trunk/reactos/base/setup/usetup/muilanguages.h
> trunk/reactos/media/vgafonts/vgafonts.rbuild
On Thu, Apr 16, 2009 at 12:57 AM, <hyperion(a)svn.reactos.org> wrote:
> Author: hyperion
> Date: Thu Apr 16 08:57:28 2009
> New Revision: 40541
>
> URL: http://svn.reactos.org/svn/reactos?rev=40541&view=rev
> Log:
> This is why we can't have nice things. Reverting r40536, r40537, due to RosBE differences between Windows and Linux hosts (because RosBE sucks)
I don't think this is fair to the guys that have put a lot of hard
work in to RosBE.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I called a feature freeze if you have not noticed.
WBR,
Aleksey Bragin.
On Apr 16, 2009, at 6:27 AM, hyperion(a)svn.reactos.org wrote:
> Author: hyperion
> Date: Thu Apr 16 06:27:50 2009
> New Revision: 40538
>
> URL: http://svn.reactos.org/svn/reactos?rev=40538&view=rev
> Log:
> Rbuild rationalization commit, umpteenth of infinite
> trunk/press-media/presentations/Imaginatica 2009/reactos_imaginatica.pptx
Could we rather save such files as PPT?
As far as I know, there is currently no loss in information if you save a
file as PPT instead of PPTX in PowerPoint 2007. Furthermore, this makes it
possible to open and edit such files with older PowerPoint versions or
OpenOffice.
Additionally, neither the PPTX import nor the ODP export (looking at the
other Imaginatica presentation) of OpenOffice seem to work as reliable as
the PPT import yet.
Best regards,
Colin
Those of us willing and able to help you test telnetd already are building
rosapps.
On Apr 15, 2009 2:13 AM, "Steven Edwards" <winehacker(a)gmail.com> wrote:
On Tue, Apr 14, 2009 at 2:14 PM, Ged <gedmurphy(a)gmail.com> wrote: > Because
we recently had a discus...
Sure I agree with keeping down the build time but I thought we were
going to implement a subset of build targets so the apps that make up
the main distro would still be in the reactos checkout. If there is
consensus that telnetd should be disabled or set to manual then I'll
turn it off. Otherwise my plan was to leave it on until we reach 0.4
in the hopes that people would stress it out and help me develop it.
Thanks
-- Steven Edwards "There is one thing stronger than all the armies in the
world, and that is an id...
Ros-dev mailing list Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
On Apr 12, 2009, at 9:07 AM, cgutman(a)svn.reactos.org wrote:
> - /* Is this correct? */
> - TdiCloseDevice( FCB->Connection.Handle,
> - FCB->Connection.Object );
Turned out it was not :)
I think we should make an exception for the downloader tool and move it out
of rosapps into the main source.
I think the argument for having it in there would exceed the argument
against.
Any thoughts?
http://www.winehq.org/pipermail/wine-cvs/2009-April/054575.html
LOL with tears,
The accuracy of this will kill your research and give you a headache.
It is so sad for a professional to commit and propagate
misinformation, it smacks of counterintelligences. I'm starting to
feel sorry for that project. It's not a state secret to match what is
published as a standard from microsoft.
8^(
James
It's a stoneage "bug", which was present from the very beginning of
ReactOS's installer (usetup) - it read, recognized and could be
installed only on the first primary partition. Now, after my today's
commits it recognizes and could be installed to any primary
partition. Extended partitions logic was not changed, was not tested
and hopefully didn't regress (if it was existing at all).
However, there is still a bug preventing booting ReactOS from non-
first partition, probably due to incorrect freeldr.ini. Everyone is
welcome to have a look and try to fix it.
Also, very important, don't use create/delete partition functionality
- it's good only to create or delete only one primary partition. If
you use it with multiple primary partitions, it's gonna mess up
everything. Again, patches are welcome.
WBR,
Aleksey Bragin.
On Apr 9, 2009, at 10:59 PM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Thu Apr 9 22:59:28 2009
> New Revision: 40430
>
> URL: http://svn.reactos.org/svn/reactos?rev=40430&view=rev
> Log:
> - Make it possible to assign drive letters to all partitions, not
> only to the first partition of a primary partition table.
> - Make AssignDriveLetters in partlist.c to actually assign drive
> letters to all partitions found (the list corresponds to how
> Windows 2003 install CD assign driver letters, but more
> investigation would not hurt).
> - Make CheckActiveBootPartition actually search for partition with
> a boot flag, instead of hardcoding it to partition 0 of disk 0.
> - Fix SetMountedDeviceValues to take multiple partitions in a
> partition table into account.
> - Fix Select Partition, Format Partition, Check File System, Delete
> Partition interface page to take partition number into account.
> - IMPORTANT: Create/Delete partitions must not be used to
> repartition the harddrive! They can only be used to create/delete
> an initial primary partition on a clean harddisk.
>
> Modified:
> trunk/reactos/base/setup/usetup/interface/usetup.c
> trunk/reactos/base/setup/usetup/partlist.c
> trunk/reactos/base/setup/usetup/partlist.h
On Thu, Apr 9, 2009 at 8:42 AM, <fireball(a)svn.reactos.org> wrote:
> Author: fireball
> Date: Thu Apr 9 16:42:09 2009
> New Revision: 40428
>
> URL: http://svn.reactos.org/svn/reactos?rev=40428&view=rev
> Log:
> - Recognize up to 4 partitions inside every primary partition table. However, installation will be performed to the first partition anyway.
How is this going to work for GPT disks? I am not quite sure about how
the bootcamp emulation does its magic. Logically it seems to me the
BSD slice would seem to be the first partition and bootcamp would show
up as partition 2. Are we not going to be able to do this?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
I had a chat with Olaf a few days ago, regarding a few issues, and we
thought it would be beneficial to bring them up for collective
brainstorming.
Background information: In the past and nowadays work in ReactOS is
getting done "as it flows". E.g. if we get developers, who wanted to
implement sound support, would do it, and we advertise this in a
release. Or, like Evgeniy Boltik who shows a nice cooperation with
Timo, Jim and Ged on fixing various nasty palette and drawing issues
which were not touched for a few years, often fixing errors
introduced in revisions like 1000 or 4000.
There is no central plan, just a very rough roadmap, mainly
relatively short-term.
Same applies to testing team: we usually perform testing when an
obvious problem occurs, in our very well known apps list, which
someone remembers to work in a certain revision. If that's known to
regress, Olaf usually organizes a regression-testing, a guilty
revision is found, and problem hopefully gets fixed.
All of this is very good, for an operating system which is developed
just for the sake of development: noone sets any milestones, noone
demands to meet them. And noone pays for achieving them either.
But when Linux got a real spin-off? An answer is: when it aimed to
become useful for the most needed application - as a platform to run
a web server and a mail server. http://en.wikipedia.org/wiki/
Linux_adoption says that in 2001 Linux servers experienced 15% annual
growth rate, and by 2004 50% of the worldwide blade servers are
shipped with Linux-based OS.
This was preceded by hard work of a number of people, like Andrew
Morton. Who aimed not just at gettign more and more features, but
more at getting existing code as stable as it's possible. That
included going through all the issues people reported, asking them to
provide more info if needed, finding the actual bug, fixing it,
asking them to retest... At some point all most frequently
encountered bugs were fixed, and potential Linux usage base extended
substantially.
For ReactOS, we have different aims, but we could use this strategy
now, when core parts of our operating system are becoming feature-
complete and mostly need debugging, and when we finally are getting
very close to going Beta.
This involves, first of all, getting hardware support at a decent
level. From a billion of personal computers in the world, we could
easily support the most common hardware without need to develop
complex drivers or different HALs. Even SATA would not really be a
strong requirement, since most of PCs have IDE compatibility mode,
which many non-technical people even forget to switch to "SATA" mode
in the BIOS when installing their Windows OS! Again Linux's
philisophy could help us: they are proud that their hardware is Linux-
compatible, while we are embarrased that "our OS doesn't support
specific hardware". Feel the difference.
Some good step in this direction is this wikipage: http://
www.reactos.org/wiki/index.php/Supported_Hardware/Network_cards
Next, software. We have a unique situation when our OS targets a vast
amount of WinAPI compatible software. There is a lot of bugs in our
Win32 subsystem, however if we can find a set of apps we support
right now, or find common software which we could easily support - it
should be our "road ahead".
Now back to what I started writing this email about. I was speaking
with Olaf and Klemens about the software compatibility database.
Existing "Support Database" is not used by people, and not liked by
most of our developers and testers because it takes more time to file
an entry into that database than to actually install ReactOS and test
the app. Another problem is that community-driven database won't work
since we can't confirm people's data.
What we thought would work good so far is a list of working apps. As
Olaf said: "it'll be ugly, not scientifically statistically fine,
crude comparing to wine appdb and limited. Bit it can be done". The
amount of text to enter for an app entry must be as minimal as
possible: app name, platform (real hardware, emulator), bug number in
bugzilla for possible issues (max. 2 bugs for one entry).
Also, no division for "installs, but doesn't start" or "works only
via manual installation". Either it works, or it doesn't, no
intermediate stages.
As we thought later, it may even be just three columns: appname, ROS
revision, Comments.
A wikipage could suit this need, but if necessary, we could think
further of some web-app.
I think that's enough for one email, I'll be glad to listen to
comments and more ideas. Everyone is welcome to take part in the
discussion.
With the best regards,
Aleksey Bragin.
I`ll participate in testing team, no matter what shape or methode will be
chosen, this is above discussion. The approach should be discussed though.
In the years i`ve been with ROS, we had a remarkable increase in stability,
from the point when you had to be careful to finish up the planned test, so
ReactOS doesnt hang in the process, to the point when you actually have to
try hard to crash it. Certainly, we are stilll miles from being rock solid,
but the progress has been made. We have one primary problem with our
project: too many problems at the same time. Its not only stability (with
Mm, Cc and vfat issues) or hardware support (unimplemented PnP and HAL,
busted resource reporting), or Win32 subsystem issues Timo has pointed. At
the same time we have problems with WINE userland and their approach to
implementation, general code untidyness, header mess, miriads of old and
often undocumented hacks, on which future assumptions were made,
rbuild/compiler issues, lack of decent debugging tools, general lack of
manpower in all areas, lack of standarised testing platform as well as
problems determining our future goals or attracting more publicity. I think
you could add a bunch more.
You know what? We try to solve all of those problems at once. And yet we are
unable to finish off a single one.
First of all sorry because i dont have idea how to follow a thread when answering one post. And i didnt find any info about how to do that :)
Now about the Topic:
Some days ago I made one Wiki Page which ( I hope) could be useful for Testing purposes. It was created just to share suggestions among Devs and Testers about it. Here it´s: http://www.reactos.org/wiki/index.php/Testing_Central
The idea is to have a Main Testing page which leads to proper Bugzilla reports, (as an online newspaper which sums up the info in Headers and clicking on them redirects to Full description),also it can help to have info of the same App together so we can track working/no working Apps instead working/no working Bugs(which is Bugzilla Work).
To sum up the Wiki page is divided in 3 sections:
1)Testing Apps:
In an easy way we can find which Bugs are preventing the Apps working, and easily redirect to the Bugzilla reports.
I think this is (almost) Aleksey proposal.
The table has the following Cols: Tester Name, App Name,Revision,4 columns for the 3 VM+RH, Bug Installing,Bug Working.
2)Developer Request:
This is a Post-it Table. Here any Dev can write any request (related with testing),so it creates a small TODO list for Testers. Of course it can link to other Wikipages. (i.e : Aicom request about testing Network cards fits here)
I have seen a lot of Dev requests in Bugzilla (i.e: "please test this TestBox", or "please test more Apps which uses Pipes", etc...), there isnt any search option to find these requests in Bugzilla, so this Table could track them.
The table has the following Cols: DEV,Request,Application/TestBox,Way of Testing,Tester, LRT (Last Revision Tested),RESULT
3)Regression Testing:
When a Regression is found a Regression Search begins, or maybe not..because the Tester/Dev doesnt have time enough to begin with it. To avoid losing this info the Regression Testing Table is created, you can fill it with a Regression you have found and other testers can work in it. But the main objective is to Coordinate efforts among Testers, so in Real Time Testers who are performing a regression test doesnt waste time: Testers can see which Revisions are being tested and which is the current Gap so they can guess which is the best revision to test. Also if one Regression Search (by any chance or missing builds ;) ) was left without finding the guilty revision,we will have a GAP for future testing.
The table has the following Cols: Name,Regression,4 columns for the 3 VM+RH,Works Rev,Fails Rev,Current Testing.
Any comments,suggestions,or criticisms are wellcome. For a full detailed description visit the Wiki page :)..it´s just a prototype and of course un-official.
Víctor Martínez Calvo
vicmarcal
_________________________________________________________________
El nuevo Windows Live te une a los que más quieres
http://www.windowslive.es
Hi,
how about using a different repository for all web-specific stuff we
have? Vendor drops of web apps, whole trunk/web, etc. All of these
are totally unrelated (in terms of repository-internal relations)
with the actual OS components.
Current situation went from long time ago when there was only one
repository possible. It's been a long time since we migrated to svn://
svn.reactos.org/repostiory/... path, so it's possible now.
rosweb, or web could be a name for a new one.
Comments are welcome.
WBR,
Aleksey Bragin.
+1
I'd like to see all the non-OS stuff put in a separate repository, including
the promotional stuff in /media.
WD
On Apr 6, 2009 11:36 AM, "Aleksey Bragin" <aleksey(a)reactos.org> wrote:
Hi,
how about using a different repository for all web-specific stuff we
have? Vendor drops of web apps, whole trunk/web, etc. All of these
are totally unrelated (in terms of repository-internal relations)
with the actual OS components.
Current situation went from long time ago when there was only one
repository possible. It's been a long time since we migrated to svn://
svn.reactos.org/repostiory/... path, so it's possible now.
rosweb, or web could be a name for a new one.
Comments are welcome.
WBR,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Evgeniy Boltik complains that EBRUSHOBJ_vInit is necessary because it
has something to do with changing brush color or palette. He's going
to file a bug about it in BZ.
WBR,
Aleksey Bragin.
On Apr 1, 2009, at 5:49 AM, tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Wed Apr 1 05:49:18 2009
> New Revision: 40306
>
> URL: http://svn.reactos.org/svn/reactos?rev=40306&view=rev
> Log:
> win32k brush update:
> - fix EBRUSHOBJ_vSetSolidBrushColor
> - Initialize text and background brush in DC_AllocDC
> - Update the DCs EBRUSHOBJs on demand
> - Use the DCs EBRUSHOBJs for drawing where appropriate
> This makes things faster and finally adds support for DC_BRUSH and
> DC_PEN
>
> - EBRUSHOBJ_vInit(&dc->eboLine, pbrushPen, dc->rosdc.XlatePen);
> -
> - EBRUSHOBJ_vInit(&BrushInst, pbrush, DCDest-
> >rosdc.XlateBrush);
That was from bug 4294, and test app was in bug 4294 too.
WBR,
Aleksey Bragin.
On Apr 4, 2009, at 10:52 PM, fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sat Apr 4 22:52:14 2009
> New Revision: 40363
>
> URL: http://svn.reactos.org/svn/reactos?rev=40363&view=rev
> Log:
> Evgeniy Boltik <bstsoft(a)narod.ru>
> - Enable and use mask support in UserDrawIconEx, fully compatible
> with Windows, based on tests in bug 4336.
> - Remove IntSet[Text/Bk]Color hacks from UserDrawIconEx, no longer
> required due to fix in CreateCompatibleDC.
> - Change a few comments in the code of UserDrawIconEx.
> See issue #4336 for more details.
Hi,
I researched my partition problem (in my hardware setup, I have an
IDE harddisk, which has 3 primary partitions, and I don't want to use
the first partittion), and sharing my findings.
So far, kernel and drivers have all necessary support and the problem
is in usetup directly. Right now, it stores information about
partition tables in a linked list of PARTENTRY structures, and
displays ONLY the information about the first out of 4 possible
partititions in that entry.
I checked with Windows 2003 installation CD, it showed me all my
partitions as they are, without limiting me anyhow. And certainly it
allows installation on any of those partitions.
Anyone volunteers to fix this problem properly?
WBR,
Aleksey Bragin.
Hi,
I'd like to let you know our application has not been accepted into
Google Summer of Code, for the third time in a row. I attached an
(autogenerated) reply, which encourages us to reapply for future
instances of the program. I would not find a better way to express
sarcasm than asking us to reapply in future.
Amongst accepted organizations there are:
WinLibre - a distribution of opensource software for Windows platform.
Battle for Wesnoth - a free turn based strategy game.
Umit - a frontend for a network scanner (one of their GSoC ideas is
to create a "Umit Assistant" which would look like a Clippit - the
animated assistant that features Microsoft Office).
TurboGears - a web framework written in Python.
Thousand Parsec - a bunch of games based on a common framework for
building turn based space empire building games.
Systers: Woman in computing - a community of women in computing. For
some strange reason the founding person is "Robin".
Singularity Institute for Artificial Intelligence - non-profit org
founded to develop safe artificial intelligence software and to raise
awareness of dangers of AI technologies.
I just stated a few examples. I highly value those projects, however
I just can't understand that yet another framework in python, or a
game engine for a turnbased strategies, or a collection of FOSS
software for Windows with a package manager (which we already have,
and which could have been improved), or an institution which believes
that AI takes over the world and tries to stop that are way more
important than supporting an organization whose product would be of
use for millions of people, and would create a real alternative
operating system compatible with the vast majority of existing
software and hardware.
Our friendly OS project Haiku gets accepted every year, so being an
OS is not a problem.
Wine is certainly accepted every year from the beginning, and this
year is not an exception. So it's definately not a problem of "legal
fear" of Microsoft.
What is the problem then? I leave it to you to decide what's the
problem. However, as for me, I see Google Summer of Code is nothing
close to supporting free software world, but rather an expensive way
of advertising.
I want to hope I am wrong.
With the best regards,
Aleksey Bragin
ReactOS Foundation President.
---------- Forwarded message ----------
From: <socghop.noreply(a)gmail.com>
Date: Thu, Mar 19, 2009 at 12:48 AM
Subject: Thank you for your application
To: xxx(a)reactos.org
Hi Aleksey Bragin,
Thank you for submitting "ReactOS" organization application to Google
Summer of Code 2009. Unfortunately, we were unable to accept your
organization's application at this time. We received many more
applications for the program than we are able to accommodate, and we
would encourage you to reapply for future instances of the program.
Best regards,
Google Open Source Programs
Hi!
Fixed in 40308!
Thanks,
James
On Tue, Mar 31, 2009 at 8:59 PM, Timo Kreuzer <timo.kreuzer(a)web.de> wrote:
> These are already in win32k/include/desktop.h
>
Hi everyone,
Lately I wanted to use latest debug builds to do some testing but they weren't yet available, can't we upload them before doing the tests? This way they'd be ready sooner for us to use...
Regards,
Gabriel.
_________________________________________________________________
Quante ne sai? Scoprilo con CrossWire!
http://clk.atdmt.com/GBL/go/140630367/direct/01/
Hello,
I'd like to improve the existing situation we have with Wine syncing.
Right now, we have a group of people, occasionally doing Wine syncs,
and that group of people included me some time ago too. However, date
was never really specified, and syncing happens "when someone wants
to sync", "before releasing", or when something is fixed in Wine and
we import that code.
How it should happen (in my opinion). All non-forked DLLs, tools and
programs must be synced after each Wine minor release. This is going
to be manual process, so we need a person to organize this process,
and a few people who could participate in doing actual work (syncers).
What this "team" leader / responsible person should do:
* Share the work (modules) between syncers.
* Leave hard-to-sync modules to experienced developers and himself.
* Ensure all syncers are instructed to do basic testing (running our
"golden" list of apps - FireFox, AbiWord, mIRC, and testing ole32/
rpcrt4/widl with a real app which uses OLE mechanism) before
committing the work.
* Be aware about syncing dependencies (e.g. when syncing widl, it
makes sense to sync rpcrt4 simulteneously)
* Be aware about problematic syncs (like icmp.dll sync, which
possibly introduces memory corruption, and which is still not fixed
in Wine).
* Keep a log of what has been synced, what has not, keep a note of
all problems.
If that proves to work good, this team may be officially announced as
"wine syncing team".
There are already at least two successfully working teams this way:
Bugzilla maintaining (with Amine being the maintainer, and my point
of contact when I want to complain or ask about something), and
Testing team (with Olaf being often my point of contact, and
organizing and doing all the hard work of regress testing, testing
apps, drivers, real hardware testing and getting results submitted).
Also, I think those two teams cooperate the best.
I wish we could expand this idea to the Wine syncing team, and get it
to work that smoothly too, and that cooperative too.
With the best regards,
Aleksey Bragin.
Hi!
2009/3/29 <jmorlan(a)svn.reactos.org>:
> Author: jmorlan
> Date: Sun Mar 29 23:17:45 2009
> New Revision: 40289
>
> URL: http://svn.reactos.org/svn/reactos?rev=40289&view=rev
> Log:
> Make cmd able to (sort of) work without a console.
Thanks! I am now able to run telnetd and connect in to my ReactOS VM.
Certain applications such as ctm don't seem to like running without a
console due to making calls to GetConsoleMode. I am going to test
telnetd on Windows with Windows cmd.exe and ReactOS cmd.exe to compare
behavior of these applications. Its possible cmd.exe returns some
bogus console mode or something when running without a console.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I unsubscribed email feedback(a)examiner.com, since it sends out
everyone an email "thank you for your feedback".
Sorry for inconvinience... People should think more when subscribing
with such stupid autorepliers.
WBR,
Aleksey Bragin.
Hi!
On Sun, Mar 29, 2009 at 1:13 AM, <jmorlan(a)svn.reactos.org> wrote:
> Author: jmorlan
> Date: Sun Mar 29 09:13:35 2009
> New Revision: 40280
Would you mind taking a look at a cmd.exe bug Wax found? (I can't log
in to bugzilla to file a bug report but I can quickly describe the
issue) For some reason the CreateProcess call in in telnetd that
spawns cmd.exe causes it to generate the error INVALID_HANDLE_VALUE.
This issue does not happen with ReactOS telnetd on windows if you use
Windows cmd.exe or if you use another console application on ReactOS
such as ping.exe so we have isolated it to a cmd.exe problem.
Telnetd is located in rosapps/sysutils/applications/telnetd
Thanks!
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
I searched for everywhere in the source code to see the definition of
the MMVAD struct, but it is nowhere.
So I suppose that we have something else (with different name) for
that? If so, where is it?
Thanks,
Jun
Hi.
I suggest to divide rosapps on two parts:
1) Components which are present in Windows (rosapps)
2) 3rd party components (3rdapps)
In rosapps it is necessary to place all components without which the
system can normally work (calc, hh, winhlp32, charmap, games and etc)
In 3rdapps components which are not present in Windows (downloader,
imagesoft and etc) will take places
Such placing of components will allow to reduce compilation time as you
can not compile not the modules necessary to you (rosapps and/or 3rdapps)
Please tell your opinion on my proposition.
--
WBR,
Dmitry Chapyshev
Are you all receiving this automated reply when sending mail to ros-dev ML ?
Kind regards,
Sylvain Petreolle
________________________________
De : feedback(a)teamexaminer.com
À : spetreolle(a)yahoo.fr
Envoyé le : Vendredi, 27 Mars 2009, 11h20mn 09s
Objet : RE: [ros-dev] Re : Where is MMVAD struct?
Thank you for your feedback. Your email will be reviewed and processed accordingly.
Sincerely,
Examiner.com
Hello everybody,
As you might have noticed, I recently did some changes to our Website stuff
and Regression Testing System.
Finally, it's time to show some results now:
== BuildBot upgrade ==
Christoph reinstalled the latest version of BuildBot on our Swedish server
today, since the previous server system was way too old for such an upgrade.
This also had the uncomfortable side-effect of the BuildBot URL changing
from http://reactos.org:8010 to http://build.reactos.org:8010, which most of
you already seem to have noticed ;-)
Sorry for not giving a note about this before.
I thought I could just finish my stuff and then write this E-Mail explaining
all changes, but as always, it took longer than expected :-/
== Crash Recovery in rosautotest and sysreg2 ==
In the recent days, I rewrote rosautotest in C++ for getting a more
maintainable code. This update also added a Crash Recovery feature.
Together with my updated version of sysreg2, we can now resume the testing
process with the next test in case a specific test made ReactOS crash.
== Web Test Interface ==
As we recently set up a new VM, which will eventually replace our current
outdated www.reactos.org server, I finally had a playground for my third
component of our testing system: The "testman" Web Interface.
It is available at http://79.99.5.181/testman/
Features include finding specific test results through a getbuilds-like
interface and comparing them.
The Comparison feature can compare up to 5 results side-by-side and show the
differences. Clicking on "Show only changed results" will only show the
lines that have differences. You can also use Drag & Drop to move the column
headers with all associated results to get the table to look like you want
it.
Clicking a test result will show details, including a log of this specific
test.
Just play around with it a bit and you should easily get to know about all
features.
Regarding Lone_Rifle's interface at http://reactos.nxserve.net: From what he
told me, this one was only meant as a decentral alternative as long as we
don't have "testman" on an official server.
I'm saying this, so nobody gets the impression that I just wanted to
extinguish his work with my implementation. If some people prefer
Lone_Rifle's version over mine, it would just need to be adjusted to the new
BuildBot URL and those people could still use it.
Comments and suggestions are welcome of course.
Not everything works perfect yet (e.g. the Debug Buildslave needs quite some
time now as all tests are run), but it should be ready for you to try now.
Best regards,
Colin
Hi,
Since today, I cannot access the old buildbot page
(http://reactos.org:8010/) anymore.
I found the new URL (http://build.reactos.org:8010) in Colin's commit
message.
Was this an intentional change?
I am asking because noone announced this change and some people might
now wonder where the buildbot page is...
Or am I the only one accessing it via my favourites? Is there even a
link from the website (I couldn't find one)?
Ah... and the old page had an icon, the new one doesn't.
Timo
PS:
The nice regtest pages at http://reactos.nxserve.net also don't work
anymore.
They were very useful and I'd like to see them up again.
So a) do we have something like that for our website (or in work)?
Or b) can this one be fixed? (I forgot who owns it.)
In a previous message you said:
>Alex Ionescu wrote:
>> This new hack directly slows down every context switch instead of every
>> page fault -- the latter is a less important perf hit.
>
>This slowdown is very small, especially when comparing with other
>"Hack of Doom".
>I just want to see, is it the only raison d'être of that old hack or not.
Could you explain the reason you add Mm Hack of Doom again if the
slowdown is very small?
Regards,
--
Matthieu Suiche
On Mon, Mar 23, 2009 at 1:56 AM, <dgorbachev(a)svn.reactos.org> wrote:
> Author: dgorbachev
> Date: Mon Mar 23 03:56:01 2009
> New Revision: 40181
>
> URL: http://svn.reactos.org/svn/reactos?rev=40181&view=rev
> Log:
> Add "REACTOS Mm Hack of Doom" again (removed in r39723). Bug #4296.
>
> Modified:
> trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S
> trunk/reactos/ntoskrnl/ke/i386/trap.s
>
> Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/ctxswitch…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S [iso-8859-1] Mon Mar 23 03:56:01 2009
> @@ -389,9 +389,6 @@
>
> /* Checking NPX, disable interrupts now */
> mov eax, [esi+KTHREAD_INITIAL_STACK]
> -
> - /* HACK */
> - mov ecx, [eax - 4]
> cli
>
> /* Get the NPX State */
>
> Modified: trunk/reactos/ntoskrnl/ke/i386/trap.s
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/trap.s?re…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] Mon Mar 23 03:56:01 2009
> @@ -1924,10 +1924,14 @@
> NoFixUp:
> mov edi, cr2
>
> + /* REACTOS Mm Hack of Doom */
> + test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK
> + je HandlePf
> +
> /* Enable interrupts and check if we got here with interrupts disabled */
> sti
> - test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK
> - jz IllegalState
> + /* test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK
> + jz IllegalState */
>
> HandlePf:
> /* Send trap frame and check if this is kernel-mode or usermode */
>
>
Hi,
I am doing a project on implementing VFS. Can anyone help me as a mentor?
Since I'm more used to in Linux than in ROS code, it would be a great help
if someone can help me through. I have gone through the ntos folder and read
some documents and also the winvfs project that someone here suggested. I'm
aware this is not a prime target in the ROS team, but once I complete this,
I might be able to contribute to areas of higher priority.
Hoping for a positive reply,
Thank you.
--
Mahesh M
Happy hacking...
, ,
/ \
((__-^^-,-^^-__))
`-_---' `---_-'
`--|o` 'o|--'
\ ` /
): :(
:o_o:
"-"
What was wrong with a previous naming convention?
x0gone.c were supposed to contain implementation of functions, which
became legacy in that major version of NDIS. Now you substituted it
with x0stubs.c, which means it's going to contain stubs only. Was
that intentionally?
On Mar 21, 2009, at 12:29 AM, cgutman(a)svn.reactos.org wrote:
> Author: cgutman
> Date: Sat Mar 21 00:29:53 2009
> New Revision: 40142
>
> URL: http://svn.reactos.org/svn/reactos?rev=40142&view=rev
> Log:
> - Reorganize NDIS code
>
> Added:
> trunk/reactos/drivers/network/ndis/ndis/30stubs.c
> - copied, changed from r40140, trunk/reactos/drivers/network/
> ndis/ndis/40gone.c
> trunk/reactos/drivers/network/ndis/ndis/40stubs.c
> - copied, changed from r40141, trunk/reactos/drivers/network/
> ndis/ndis/50gone.c
> trunk/reactos/drivers/network/ndis/ndis/50stubs.c
> - copied, changed from r40113, trunk/reactos/drivers/network/
> ndis/ndis/stubs.c
> trunk/reactos/drivers/network/ndis/ndis/misc.c (with props)
> Removed:
> trunk/reactos/drivers/network/ndis/ndis/40gone.c
> trunk/reactos/drivers/network/ndis/ndis/50gone.c
> trunk/reactos/drivers/network/ndis/ndis/stubs.c
Hi,
1.) Is there a reason, why some exports of advapi32 are forwarded
instead of just set to the proper function? Forwarding is more work for
the loader.
2.) kernel32 imports from itself. Which will probably lead to the same
result as bug 4292.
This is because the mingw lib imports from kernel32 and requires
kernel32 library to be added afterwards. But rbuild likes to add mingw
lib at the very end of the library list which requires adding kernel32
as a library to mingw_common to resolve imports. This should be fixed
and mingw added as the very first library.
I wonder if those 2 are even allowed on Windows, as both don't make sense.
Timo
Hi All!
Good to see it go, I had it in as a safeguard, and now we moved on to
the next phase of the rewrite!
Thanks Timo!
James
8^D
On Fri, Mar 20, 2009 at 4:47 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> Oh, finally! ;)
>
> On Mar 20, 2009, at 7:51 AM, tkreuzer(a)svn.reactos.org wrote:
>
>> Author: tkreuzer
>> Date: Fri Mar 20 07:51:26 2009
>> New Revision: 40115
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=40115&view=rev
>> Log:
>> rename DCs pDc_Attr to pdcattr, like in gdikdx.
>> Make pdcattr alsways point to a DC_ATTR, either the user mode
>> struct or the local part. Get rid of all the If (!pdcattr) pdcattr
>> = &dc->Dc_Attr; That are not required anymore.
>
Oh, finally! ;)
On Mar 20, 2009, at 7:51 AM, tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Fri Mar 20 07:51:26 2009
> New Revision: 40115
>
> URL: http://svn.reactos.org/svn/reactos?rev=40115&view=rev
> Log:
> rename DCs pDc_Attr to pdcattr, like in gdikdx.
> Make pdcattr alsways point to a DC_ATTR, either the user mode
> struct or the local part. Get rid of all the If (!pdcattr) pdcattr
> = &dc->Dc_Attr; That are not required anymore.
Hi,
I's like to suggest a workaround to the problem that we have to deal
with both RECT and RECTL structures in win32k and as they
are incompatible need to typecast in a lot of places.
RECTL is what the DDI interface uses (almost) exclusively. While the
NtGdi Interface and a lot of User structures also use RECT.
Both structures are equal, but not compatible when it comes to assigning
one to another, So we need to do all these nasty typecasts.
My suggestion is adding some defines after the inclusion of windef.h:
#define RECT RECTL
#define PRECT PRECTL
#define LPRECT LPRECTL
#define LPCRECT LPCRECTL
same for POINT and POINTL
I'd like to hear your opinion on that.
Thanks,
Timo
Looking at the patch only this looks wrong to me.
Assuming this is radio button it should use the marlett font.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org
Sent: 04 March 2009 16:30
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [mkupfer] 39871: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details.
Author: mkupfer
Date: Wed Mar 4 19:29:57 2009
New Revision: 39871
URL: http://svn.reactos.org/svn/reactos?rev=39871&view=rev
Log:
Sascha Clausen <r4v3r AT hotmail DOT de>
- Draw bullet for menu radio group.
- See issue #4193 for details.
Modified:
trunk/reactos/dll/win32/user32/windows/draw.c
Modified: trunk/reactos/dll/win32/user32/windows/draw.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/windows/d…
==============================================================================
--- trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] Wed Mar 4 19:29:57 2009
@@ -1276,11 +1276,12 @@
yc = myr.top + SmallDiam - SmallDiam/2;
i = 234*SmallDiam/750;
i = i < 1 ? 1 : i;
- myr.left = xc - i+i/2;
+ myr.left = xc - i/2;
myr.right = xc + i/2;
- myr.top = yc - i+i/2;
+ myr.top = yc - i/2;
myr.bottom = yc + i/2;
- Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye, xe, ye);
+ // if the start and the end point are equal, Pie() only draws a single line, so start one pixel lower
+ Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye+1, xe, ye);
break;
case DFCS_MENUCHECK:
It's not UserDrawIconEx which is hacky, it's just the code you added for detecting alpha pixels
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org
Sent: 13 March 2009 00:21
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests.
Author: mkupfer
Date: Fri Mar 13 03:20:48 2009
New Revision: 39997
URL: http://svn.reactos.org/svn/reactos?rev=39997&view=rev
Log:
- Add a hackfix comment for issue #4243 due to several requests.
Modified:
trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c
Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt…
==============================================================================
--- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original)
+++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 03:20:48 2009
@@ -1389,6 +1389,7 @@
}
+/* FIXME: ReactOS specific hack */
BOOL
UserDrawIconEx(
HDC hDc,
The only things I have habitually used in rosapps are ctm, ncftp, and
download. I'd hate to see these go away. OTOH, there are quite a few
things that l would consider "tests" in rosapps that could be moved. I
think the argument that rosapps to long to build is crap. If you want to
reduce the build time, ditch explorer.
On Mar 12, 2009 11:02 AM, "Ged" <gedmurphy(a)gmail.com> wrote:
I prefer this idea.
I'd like to see rosapps removed completely and have all non essential stuff
in trunk built via an rbuild variable (turned off by default)
Ged.
-----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:
ros-dev-bounces(a)reactos.org] ...
Behalf Of Thomas Bluemel Sent: 12 March 2009 14:17 To: ReactOS Development
List Subject: Re: [ros-de...
Hi Guys,
One of the big issues I'm seeing with regards to ReactOS is the lack
of overall structure. Currently ReactOS is loosely compatible with
NT, 2000, XP, and even Vista. However, I believe that in order to
achieve true stability and compatibility some changes should be
implemented. I'm offering my opinion as a suggestion of how to
structure things. While I believe that everyone should be allowed to
have fun developing a great project, I believe that we can still do
this, while maintaining a little more structure. Please feel free to
comment on this email.
First Issue: Moving Target
Every since I first started watching ReactOS in 2001, I've noticed
that ROS is suffering from moving target syndrome. Microsoft
continually releases new versions of Windows each year, and ROS
struggles to keep up. driver compatibility, app compatibility, etc.
are all affected by this. Development is all over the place. If
someone knows how to implement a vista API call, they do it. XP?
Same, etc. The problem is this can cause compatibility issues with
drivers and apps that do DLL hooking, as well as other oddball
scenarios. In order to have truely 100% compatibility, we need to
find a way to deal with this type of development.
I propose picking a single target, Either Windows XP or Windows 2003,
to serve as the trunk (I currently recommend Windows XP since it is
compatible with nearly everything out there.) All core development
will be based around this. Our releases will be based around this.
Branches will be created for Windows 7, Windows Server 2008, and
Windows Vista specific code. Any platform specific code will go into
this branch. Any code that is no longer valid will be removed from
this branch. This allows multiple versions of Windows to be targetted
at the same time.
The trunk will continue on it's path until a) It is 90-100%
compatible with most apps/drivers or b) XP/2003 become so old and out
of date they aren't used by anyone anymore, similar to the way
98/NT4/2000 are now. If either of those scenarios happen, we vote to
switch to a different branch. We should avoid switching to the most
cutting edge version of windows, however, and instead focus on the
most widely used version at the time.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks
in ROS, or worse, they implement ROS specific hacks in different apps.
Both of these are very bad practices. Instead of doing either of
these, I'd recommend discussing the problems you find with the other
developers over the mailing list. For instance, if app XYZ is
working, rather than submitting a hackish patch to get it to work,
find the root cause of the issue, and solve it there or ask for help
to solve it.
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That
i know of, unless it's in a seperate repo) does not have an official
testing framework. Each developer here should take some time out and
write a test for every api currently supported by windows, make it
pass on Windows, and then commit it to SVN. If we all write tests,
This will help identify bugs in ROS vs Windows. Low level tests are
ESPECIALLY needed. Our driver compatibility currently sucks, and it's
getting worse every day. Unit testing for driver specific APIs and
the HAL would help improve ROS dramatically.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in
userland. This process should be avoided. All ROS apps should work
on both Windows and ROS, and should not contain any ROS specific
checks,etc. This goes back to the second issue.
I look forward to hearing your responses to my opinion, and I hope
that we can work on getting at least some of these opinions
implemented so that we may build a truly great Microsoft Windows
Compatible Alternative!
Thanks,
Richard Campbell
Restructuring ReactOS
Hi Guys,
One of the big issues I'm seeing with regards to ReactOS is the lack
of overall structure. Currently ReactOS is loosely compatible with
NT, 2000, XP, and even Vista. However, I believe that in order to
achieve true stability and compatibility some changes should be
implemented. I'm offering my opinion as a suggestion of how to
structure things. While I believe that everyone should be allowed to
have fun developing a great project, I believe that we can still do
this, while maintaining a little more structure. Please feel free to
comment on this email.
First Issue: Moving Target
Every since I first started watching ReactOS in 2001, I've noticed
that ROS is suffering from moving target syndrome. Microsoft
continually releases new versions of Windows each year, and ROS
struggles to keep up. driver compatibility, app compatibility, etc.
are all affected by this. Development is all over the place. If
someone knows how to implement a vista API call, they do it. XP?
Same, etc. The problem is this can cause compatibility issues with
drivers and apps that do DLL hooking, as well as other oddball
scenarios. In order to have truely 100% compatibility, we need to
find a way to deal with this type of development.
I propose picking a single target, Either Windows XP or Windows 2003,
to serve as the trunk (I currently recommend Windows XP since it is
compatible with nearly everything out there.) All core development
will be based around this. Our releases will be based around this.
Branches will be created for Windows 7, Windows Server 2008, and
Windows Vista specific code. Any platform specific code will go into
this branch. Any code that is no longer valid will be removed from
this branch. This allows multiple versions of Windows to be targetted
at the same time.
The trunk will continue on it's path until a) It is 90-100%
compatible with most apps/drivers or b) XP/2003 become so old and out
of date they aren't used by anyone anymore, similar to the way
98/NT4/2000 are now. If either of those scenarios happen, we vote to
switch to a different branch. We should avoid switching to the most
cutting edge version of windows, however, and instead focus on the
most widely used version at the time.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks
in ROS, or worse, they implement ROS specific hacks in different apps.
Both of these are very bad practices. Instead of doing either of
these, I'd recommend discussing the problems you find with the other
developers over the mailing list. For instance, if app XYZ is
working, rather than submitting a hackish patch to get it to work,
find the root cause of the issue, and solve it there or ask for help
to solve it.
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That
i know of, unless it's in a seperate repo) does not have an official
testing framework. Each developer here should take some time out and
write a test for every api currently supported by windows, make it
pass on Windows, and then commit it to SVN. If we all write tests,
This will help identify bugs in ROS vs Windows. Low level tests are
ESPECIALLY needed. Our driver compatibility currently sucks, and it's
getting worse every day. Unit testing for driver specific APIs and
the HAL would help improve ROS dramatically.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in
userland. This process should be avoided. All ROS apps should work
on both Windows and ROS, and should not contain any ROS specific
checks,etc. This goes back to the second issue.
I look forward to hearing your responses to my opinion, and I hope
that we can work on getting at least some of these opinions
implemented so that we may build a truly great Microsoft Windows
Compatible Alternative!
Thanks,
Richard Campbell
Hi,
Qemu w Head:
(subsystems/win32/win32k/ntuser/desktop.c:612) RtlQueryRegistryValues
failed for PaintDesktopVersion (c0000034)
err:(base/system/winlogon/screensaver.c:86) ImpersonateLoggedOnUser()
failed with error 5
(ntoskrnl/se/semgr.c:613) Denying access for caller: granted 0x600e8,
desired 0xf01ff (generic mapping 80F290E8)
Assertion 'PointerPte->u.Hard.Valid == 0' failed at
ntoskrnl/mm/hypermap.c line 100
Entered debugger on embedded INT3 at 0x0008:0x808c1e7e.
kdb:> bt
Eip:
<NTOSKRNL.EXE:c1e7f>
Frames:
<NTOSKRNL.EXE:7c608>
<NTOSKRNL.EXE:7615f>
On Tue, Mar 10, 2009 at 4:53 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> Boot is broken for me in VMWare, with an assert being hit in
> hypermap.c:178.
>
>
> WBR,
> Aleksey Bragin.
>
Boot is broken for me in VMWare, with an assert being hit in
hypermap.c:178.
WBR,
Aleksey Bragin.
On Mar 10, 2009, at 3:31 AM, ros-arm-bringup(a)svn.reactos.org wrote:
> Author: ros-arm-bringup
> Date: Tue Mar 10 03:31:14 2009
> New Revision: 39925
>
> URL: http://svn.reactos.org/svn/reactos?rev=39925&view=rev
> Log:
> - Implement a new Hyperspace Mapping Interface:
> - The new interface is portable and much faster than before.
> For example, unmapping a hyperpage is almost a one-line operation.
> - The new interface is also thread-safe and uses the EPROCESS
> hyperspace spinlock.
> - However, in order to isolate from React Mm internals, the
> Hyper IRQL and Process are stored as globals, so this will not work
> on SMP.
> - For now, mapping vs. zero PTEs are not treated differently,
> but the two interfaces have been separated pending future work.
> - Performance tests with _rdtsc resulted in an improvement of
> over 300% compared to the old interface.
> - Hyperspace mappings are frequent, so the improvement is
> noticeable during startup (3/10ths of a second).
> - This also fixes incorrect initializtion of hyperspace --
> pages were zeroed out (which requires hyperspace) before hyperspace
> was created.
Hi,
I notice that in Windows Vista - and also Windows XP - there seems to
be an undocumented field in PEB.
>From Windbg, I found some below fields in PEB structure'
...
+0x064 NumberOfProcessors : Uint4B
+0x068 NtGlobalFlag : Uint4B
+0x070 CriticalSectionTimeout : _LARGE_INTEGER
...
We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field.
So the next field should be at 0x6C. However, CriticalSectionTimeout
is at 0x70.
- So the question is why that happens? I suspect that there is an
undocumented field after NtGlobalFlag, which is removed from the
debugging data. Any idea?
- Another thing: ReactOS now faithfully declares the PEB structure
like above, without that secret 4 bytes hole. As a result, the
ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do
we need to care about that? Or not?
Thanks,
J
On Mon, Mar 2, 2009 at 9:42 PM, <tkreuzer(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=39849&view=rev
> Log:
> Initial version of a gdi font driver for bitmap fonts (.fon / .fnt). It starts to work, but not yet correctly. Glyphs are truncated. Developed on Windows XP.
Are you planning on using FreeType in this?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
Alex Ionescu wrote:
> This new hack directly slows down every context switch instead of every
> page fault -- the latter is a less important perf hit.
This slowdown is very small, especially when comparing with other
"Hack of Doom".
I just want to see, is it the only raison d'être of that old hack or not.
Aleksey Bragin wrote:
> Why so, Dmitry? Looks like a hack?
IopEnumerateDevice() loads drivers, but link in ArcName directory for
a boot device
should exist for it.
Hi,
As you're all probably aware, myself and janderwald are in the process
of working on sound. I thought I'd give a brief update on this, but I
also need some feedback on the location of the various sound components
in our tree as I think it needs a little reorganisation.
At present, I am focusing on the user-mode portion of sound support,
with the goal of getting NT4 audio drivers working (legacy Sound Blaster
cards etc.) while janderwald is getting newer style WDM audio drivers up
and running.
I don't want to duplicate code, hence I have been intentionally
developing some helper libraries that can be easily reused. Think of
them as dedicated abstractions of the various Windows APIs with a
dedicated purpose (sound support.)
The components involved or which are planned are:
- Common library for user-mode side of sound support
- Helper library specifically for NT4 device sound support (device
"discovery" etc.)
- sndblst.dll, mmdrv.dll and wdmaud.drv user-mode DLLs (making use of
the above two components, slight variation in functionality for each -
Windows 3.1 used to use the equivalent of these as the actual drivers,
hence why there are multiple.)
- Kernel-mode common library for NT4 style sound drivers
- Sound Blaster library (to be shared between sndblst.sys and PortCls
implementation)
- UART401 library (to be shared between mpu401.sys and PortCls
implementation)
- Kernel Streaming API
- Kernel Streaming components
- Port Class driver
At the moment I have a few things dotted around a "sound" directory
within "include/reactos"
I also have some stuff in our "lib" directory (the helpers I wrote)
Kernel streaming related components seem to be spread around various
places in drivers/wdm and drivers/ksfilter
My attempts so far at NT4 drivers are still sat in drivers/multimedia
Basically, I want to try and structure this better. I don't think
sndblst.dll/mmdrv.dll/wdmaud.drv belong in dll/win32, and I'm wondering
if my helper libraries for sound should sit next to the relevant
components directory-wise. Or are they fine being in "lib"? They're only
used for sound components.
Finally, does anyone object to me removing the entire of the
drivers/multimedia tree as nothing in there works at all? I wrote most
of the code there, there is some redundant code from the very early
ReactOS days in "sound", I can leave that if it's really needed. I want
to start implementing sndblst.sys properly so I want to clean up a bit
first, but thought I'd ask first before I do anything further.
Andrew
Hi All!
When did this start? Why are we hacking application to work with ReactOS?
I see in change 39703 has gone from one kernel call to three.
Performance? We need to fix the real problem and it is a very old one
too.... SetWindowPos is very broken. Placing bandaids over a bullet
wound is not going to fix the problem. Patching around it too!
Remember adding hax on top of other hax rant I've posted over the
years. Creates more problems and these are still the problems we are
having now.
Applications must work on other target systems first prior to working
with ReactOS. TaskMgr must work on the target system first!
Evgeniy Boltik changes are based on good research but testing the
changes after is lacking. Evgeniy! Collect and create your test suite
of application and test them! AbiWord, FF, ReactOS apps and others
that are known to work before your changes. Once you get into a rhythm
of testing it becomes easier...
Thanks,
James
Hi,
we have put our efforts today to upgrade the SVN server machine,
which now runs Subversion 1.5.1, and do some routine maintenance like
recompressing the reactos repository, reconfiguring everything, etc.
As a result, some total (not even readonly access) downtime happened,
however it was only slightly more than a couple of hours, so
hopefully noone's suffered too much.
Now it runs stable, and better than before. Enjoy.
Thanks to Franz, Colin and Christoph for helping with setting up and
transferring the server. Their help is greatly appreciated.
WBR,
Aleksey Bragin.
Hi there everyone,
Thanks for the comments. Yes, i will be on IRC soon. My AIM username
is eek2121.
Thanks,
Richard Campbell
>
>
>
> On Wed, Feb 18, 2009 at 4:04 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>> Hi Richard,
>> very nice to see you back!
>>
>> Do you use IRC? If not, any other IM messenger? I could be reached as
>> fireballrus(a)gmail.com for gtalk, fireballrus in Skype, 3890063 in ICQ.
>>
>> If all the above fails, we'll just exchange emails, this is fine too.
>>
>>
>> I'll add your login to the svn, and let you know the password. Your work is
>> appreciated!
>>
>>
>>
>> WBR,
>> Aleksey Bragin.
>>
>>
>> On Feb 18, 2009, at 8:01 AM, Richard Campbell wrote:
>>
>>> Hi Guys,
>>>
>>> So After a LONG hiatus I've finally decided to get back into writing
>>> code for ReactOS. Some (most?) of you may not remember me. I've been
>>> lurking on the lists since 2000-2001, and was an active developer with
>>> CVS access for a while back in 2002-2003 (check the commit messages
>>> for rcampbell, also submitted quite a few patches). have never stopped
>>> reading (although i was/am using a different email address), but
>>> haven't touched the code before now. I have a couple of questions:
>>> 1) Is my SVN username active? The username is rcampbell. If not,
>>> I'll just use bugzilla. 2) Any documentation on coding guidelines
>>> such as styles, etc. or rules? I'm sure this has changed since my
>>> heyday.
>>>
>>> Thanks,
>>>
>>> Richard Campbell
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev(a)reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
Hi,
Does buildbot have its own custom config.rbuild that it uses? I've
been having a lot of trouble as I've been trying to boot a build in
either vmware or qemu with a virgin ReactOS source tree and RosBE-unix
and I always get hung up at the same place. buildbot builds don't show
the problem I am having so I am trying to nail down what in the
environment could cause the problem.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I've search around the ReactOS site, the mailing lists, and the Wiki, and haven't seen this subject out there much. We have an older application that runs on Windows over a network connection. The software must be run over the network and must have a mapped network drive to function correctly. I know that Samba-TNG is available for ReactOS, but this seems to only smbclient and no way to mount or map a network share. Are there any plans or current efforts to support mapped network drive functionality?
Thanks - Nick
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Hi Guys,
So After a LONG hiatus I've finally decided to get back into writing
code for ReactOS. Some (most?) of you may not remember me. I've been
lurking on the lists since 2000-2001, and was an active developer with
CVS access for a while back in 2002-2003 (check the commit messages
for rcampbell, also submitted quite a few patches). have never stopped
reading (although i was/am using a different email address), but
haven't touched the code before now. I have a couple of questions:
1) Is my SVN username active? The username is rcampbell. If not,
I'll just use bugzilla. 2) Any documentation on coding guidelines
such as styles, etc. or rules? I'm sure this has changed since my
heyday.
Thanks,
Richard Campbell
> No, it's just a matter of coding style used in the kernel.
What is a logical basis for adopting this particular rule? Sometimes it is
not just a matter of preference.
These parentheses are unnecessary for humans, and if they are not needed for
compilers or some other tools, they are bad! Without them, the bug could be
noticed earlier.
Cheers,
Dmitry
> I personally feel consistent application of the style is also important,
> and that there does not exist a reason to deviate from the established
> coding style in this situation.
I agree that it is good to follow the consistent coding style. The question
is this style itself is good.
I meant the abstract case of ((a = b) && (c = d)), not the concrete case of
((ConvKey == HashEntry->ConvKey) && (Length == Ncb->NameLength)).