Hi,
Mozilla Firefox 2.0: install it, run it, then quit - total hang
without KDBG or any exception, TAB+K doesn't work.
Then, reboot - try to navigate via Start Menu to Applications ->
Mozilla Firefox. Explorer will die with exception in dll/win32/user32/
misc/exticon.c:88 (find_entry_by_id). Maybe due to files corruption.
WBR,
Aleksey.
tkreuzer(a)svn.reactos.org wrote:
> For some unknown reason wmc likes to include string.h from the wine folder
and we cannot link it on linux hosts. This hack should hopefully resolve the
issue.
Not that mysterious actually.
The "include/reactos/wine" directory is shared among Wine host and target
tools while "include/crt" contains target-only headers and thus it's only
available for target components.
Therefore #include_next cannot find any other "string.h" file, when you use
it inside host tools. Furthermore, #include_next is a GCC-only thing, so we
should avoid it wherever possible.
To circumvent these problems and remove the hacks from the actual CRT/PSDK
headers, I propose we i.e. add '#include <reactos/wine/string.h>' to the CRT
"string.h" and do the appropriate thing for other files.
This is the prettiest solution I can think of without editing a bunch of
Wine files.
Best regards,
Colin
Sooner or later, this problem should be solved somehow. And not only for
Armenians, but also for other peoples of the world, who live without code
pages.
I concur with James.
Eric, I think what you meant to say is you don't have time to work on
ReactOS in its current state -- ie: the slow, time-consuming
procedures and behaviors that take up more than 50% of your free time.
What if ReactOS provides you with your own branch, and the ReactOS
project assumes the responsibility of merging your changes to trunk,
performing the testing and regression testing. You might be afraid
that your code will "rot" and that it would never make it inline, but
I'm sure the people respect your work as much as I do and would make
sure that things stay up to date (much like we sync with Wine).
This would allow you to keep committing code, have your own branch
which at least works for you, and we'd take care of merging. Your only
real responsibility would be to "sync up" with trunk every once in a
while -- could even be only ever 3 months, or if you notice something
obvious that might affect you (RPC changes, WIDL changes, SCM etc).
I know this may sound unfair to other developers, but as James pointed
out, you deserve everyone's time, considering how much you've put in
all this time.
On 19-Dec-08, at 9:22 PM, James Tabor wrote:
> Hi Eric!
> Eric Kohl wrote:
>> Hi!
>>
>> Effective immediately I am taking a break from working on ReactOS
>> for an
>> undetermined period of time. It may even be the end of my involvement
>> with ReactOS.
>>
>> There are several reasons for me to quit but the most important one
>> is
>> lack of time. I have a pretty exhausting job and spend more than 2
>> hours
>> a day to commute so there is not much time left to spend on ReactOS.
>> So working on ReactOS happened on weekends only.
>>
>> After my latest patch was partially reverted, I decided that I am not
>> willing to create and maintain a development branch for
>> improvements to
>> LSA and SAM. I am not willing to spend an hour or two each weekend
>> for
>> branch maintenance and debugging and another two or three hours for
>> developing new code. It just does not make sense to me.
>>
>> Maybe I will be back one day, maybe I will not. Time will tell.
>>
>> Over and out!
>> Eric
>>
> Your resignation is disapproved! You are an integral part of this
> project.
>
> You are the last of the root members of this project. We need your
> help
> and if that means breaking ReactOS truck that is your right to do
> so. We will
> learn to live with it. I have followed your work for years and I
> would like
> to see you more. Based on your tenure with this project, this gives
> you
> rights, influences and guidance to this project.
>
> Please recommence with your changes,
> James
> _______________________________________________
> Ros-general mailing list
> Ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
Best regards,
Alex Ionescu
Hi,
we are a software development company that develops and maintains a
Linux-based server solution called IServ, designed for use in schools.
We are in business since 2003, and there are currently about 370 schools
in Germany using IServ as their portal server.
One feature that we would like to integrate into our product is the
possibility to customize the ntconfig.pol file. This file, located on
the server's netlogon share, can deploy registry settings to Windows
clients - it is especially important because it can deploy
HKEY_LOCAL_MACHINE settings. This file is a binary registry hive. At the
moment, we have to create this file manually with poledit.exe.
We need a Linux program which can automatically generate this file.
1) It should read plain text files as input, for example an INF file.
2) The resulting policy file must work with Windows 2000 and XP x86
clients. It should be possible to easily test this by using the command
"Load Hive" in Regedit.
3) The preferred programming language is Perl, C/C++ is also OK. Other
languages should also be possible, but only after prior consultation
(just to make sure nobody comes up with Java ;) ).
4) The resulting source code should be released as open source, e.g.
under the GPL.
We would like the program being finished in one month. We will pay you
EUR 300 for it. If the program is very much work and you feel you need
more money, submit us an offer.
A Perl library to dump binary registry files to plain text:
http://search.cpan.org/~jmacfarla/Parse-Win32Registry-0.30/
Attachments:
ntconfig.pol - Our current policy. This must be generated automatically.
ntconfig.pol.dump - Plain text dump of that file, generated with
Parse::Win32Registry.
winnt.adm - Template to edit our policy file with poledit.exe.
Our homepage: http://iserv.eu (only in German, though)
--
Yours sincerely,
Martin v. Wittich
IServ
Falk & Ludwig GbR
Rebenring 33
38106 Braunschweig
Germany
Telephone: +49 531 380 4450
E-Mail: martin.von.wittich(a)iserv.eu
Internet: http://www.iserv.eu
hi, i'm a newbie of ReacOS.
I looked a piece of code in syscall.S which is come from 0.2.7 edtion.
/* Raise IRQL to APC_LEVEL */
movl $1, %ecx
call @KfRaiseIrql@4
could anybody help me explain why the function is decorated by @ in the head?
and why transfer argument by ecx?
Thank you
___________________________________________________________
好玩贺卡等你发,邮箱贺卡全新上线!
http://card.mail.cn.yahoo.com/
Hi,
Guys(and Girls) did you heard about a program called "stress prime"?
It was developed to calculate prime numbers. And it is very sensitive
to small errors.
Since it has some kinda detecting errors, many overclockers are using
it to confirm overclocked H/W stability.
Yes, I tried to run this program, just for fun, and surprise! The
system is not overclocked, nor has problem when running stressprime on
WindowsXP.
The rounding error amount was huge. I saw the source code of the
stress prime and I'm sorry it was assembly language, so I couldn't
check what could make such prolem under ReactOS. It was all about the
math, and I'm not good at both(asm,math)
But, one thing sure, is something is not working properly(maybe
kernel?) and it is affecting ReactOS stability.
What is your opinion? any comments?
--
Regards,
Ashuaria Lee