> Updated files:
> trunk/reactos/lib/setupapi/devinst.c
> trunk/reactos/lib/setupapi/makefile
One thing you need to do too :
stop patching this makefile and remove it from svn :)
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Developers,
Please contact me if you wish to receive a legal copy of VMWare 5.0 for
Linux.
There are 7 spots remaining, first come first serve.
Best regards,
Alex Ionescu
--- Casper Hornstrup <ch(a)csh-consult.dk> wrote:
> > Coudn't they written to hd ? On reboot reporterror would ask if he may
> > send it.
>
> Exactly.
You can't trust the system to write to the disk on a BSOD. If the crash is bad enough to BSOD then
it is bad enough to hose a fat16/32/ext2 fs. A crash that cannot be recovered from that results in
a BSOD should ONLY BSOD. If you can figure out a way to fix /DEBUGPORT=FILE to flush its buffers
and safely write to disk on BSOD I have a bounty for you. This is way doing a memory dump or
minidump of a crash is inheritly risky which is why it should be off by default.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
In these reactos\reactos\inf+media}system32 sub directories there is no
file created during the ros build by make .
Is it really needed ?
Regards
Gerard
Hi all,
After a big set back, 8^6, I've manage to get cromwell to compile with the
new build system. I have started the Fdo, Pdo and Ioctl stuff. It's cool!
I'll commit the stuff I have now and we can start working on it again.
Thanks,
James
Hi,
I'm not able to boot the current svn tree in qemu. It crashs in the very
early boot phase:
(hal\halx86\generic\acpi.c:443) Unable to locate RSDP
(ntoskrnl\ke\main.c:292)
---------------------------------------------------------------
(ntoskrnl\ke\main.c:293) ReactOS 0.3-SVN (Build 20050530-r15689)
Used memory 131072Kb
(ntoskrnl\mm\mminit.c:378) Kernel Stack Limits. InitTop = 0x800f4000,
Init = 0x800f1000
(ntoskrnl\mm\mminit.c:106) NonPagedPool 80800000 - 86bfffff, PagedPool
87000000 - 8d3fffff
******* Dumping non paging pool stats ******
Tag ffffffff Blocks 1 Total Size 3200 Average Size 3200
TotalBlocks 1 TotalSize 3200 AverageSize 3200
Freeblocks 1 TotalFreeSize 816 AverageFreeSize 816
***************** Dump Complete ***************
(ntoskrnl\mm\mm.c:327) No current process
red zone verification requested for block 0x8D3D38A8
ntoskrnl\mm\/rpoolmgr.h(708): double-free detected for paged pool
address 0x8d3d38a8
Tag (0), Size -1515870811, UserSize 0
First few Stack Frames: <ntoskrnl.exe:48> <68> <ntoskrnl.exe:62cb4>
Contents of Block:
A problem has been detected and ReactOS has been shut down to prevent
damage to your computer.
The bug code is undefined. Please use an existing code instead.
Technical information:
*** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000)
Frames:
<ntoskrnl.exe:23f7>
<ntoskrnl.exe:242f>
<ntoskrnl.exe:61f14>
<ntoskrnl.exe:61fd5>
<ntoskrnl.exe:628fb>
<ntoskrnl.exe:63240>
<ntoskrnl.exe:61100>
<ntoskrnl.exe:611b6>
<ntoskrnl.exe:4646a> PnpRootQueryBusRelations
<ntoskrnl.exe:4651e>
<ntoskrnl.exe:4658f>
<ntoskrnl.exe:46655>
<ntoskrnl.exe:40f67>
<ntoskrnl.exe:40edf>
<ntoskrnl.exe:43448>
<ntoskrnl.exe:44b41>
<800B5953>
<800B325D>
<ntoskrnl.exe:6216>
<800B16C6>
<ntoskrnl.exe:104b>
It does not crash on real hardware. An other question, how do I get back
the nostrip-files for addr2line?
- Hartmut
I built Ros with svn 15689 after a checkout ( mingw32-make ) and I
noticed that a Reactos Directory is created in the Reactos source
directory .
This is not needed.
D:\Gerard\Reactos\Svn\reactos\reactos>dir
Volume in drive D has no label.
Volume Serial Number is C4F7-46D4
Directory of D:\Gerard\Reactos\Svn\reactos\reactos
30/05/2005 23:16 <DIR> .
30/05/2005 23:16 <DIR> ..
30/05/2005 23:16 <DIR> inf
30/05/2005 23:16 <DIR> media
30/05/2005 23:16 <DIR> system32
0 File(s) 0 bytes
5 Dir(s) 3 877 736 448 bytes free
D:\Gerard\Reactos\Svn\reactos\reactos>
Regards
Gerard
Hi all
We need to vote on the UI Coordinator Vote. This will take 2 weeks
according to our voting rules and only committers may participate. If
you're not listed as a committer but participate in the project in an
important way (testing/web work) then talk to an existing committer to
get a recommendation.
For voting rules see:
http://www.reactos.com/wiki/index.php/Voting
Regards
Jason
Hi,
Since not all the developers are on IRC and/or are aware of this, I
wanted to make the following announcement so that future requests/flames
can go to the right person (ie: me).
I have registered ReactOS as an official group with Freenode, and we now
have full, legitimate control over #reactos and all #reactos-****
channels (as well as ros-dev but there is (and has always been) a remote
risk some new project called "ROS" might come and dispute that)) and
enjoy all the benefits of an actual group registration.
Since I am the group contact, that means that any requests that cannot
be done by yourselves as operators (ie: major changes, like requesting a
cloak) should be sent to me, and I'll take care of them ASAP. I'm also
currently fixing the IRC Access Lists so they work properly (people
would get operator status but not auto-voice, and other such silly
things). I have already fixed up #ros-dev so that Level 10ers get +v,
Level 20ers +o and Level 40ers have almost unlimited access. Similarly
to before, all the devs have been set to have this access level (40). In
the old system some people were 45, some were 46, some 47, etc, which
kind of made everything seem awkard (ie: "why is developer foo 44 but
developer bar 47? is bar more 'powerful'?). This resulted because
instead of having a single person assign the access, everyone tried
their best, but people can only give one access level lower then what
they already are. So in the future, just send me a pm/email and I'll add
the proper access for a new dev. But that won't be a problem since I'm
24/7 on IRC and I doubt I would not notice a new developer :). Tomorrow
I'll be fixing up #reactos, which suffers from even bigger access level
problems.
Apart from making you aware of the fact that I'm here to help for any
IRC-related business, I also wanted to say that I can now assign you
user cloaks! This means that instead of being
kjk_hyperion(a)some.random.italian.dsl.isp.it you can now be
kjk_hyperion(a)developers.reactos. I will also be handing out
@users.reactos or @testers.reactos for people who are not developers but
have been helping us quite a lot (one notable example is WaxDragon, or
tinus, etc). We can of course even have @webteam.reactos or
@translators.reactos...etc. The main advantages of a cloak is that
1) people know you're with us, and what your position is
2) Your actual ISP/Hostname/IP is hidden from the public, so you don't
need to worry about script kiddies
3) It's cool (imo)
So here's what I'll be needing from you if you want to be cloaked:
(CONTRIBUTORS ONLY FOR NOW, PLEASE!)
1) Your IRC Nickname and IRC Alternate Nickname (you *must* set one
up...and your nickname *must* have been registered to a valid e-mail
address)
2) Your choice of cloak... recommendations: (developer.reactos,
translator.reactos, media (or designer? or ui?).reactos, board.reactos)
PM me on IRC or send me an e-mail with the above information and you
should have your cloak in less then a day.
Best regards,
Alex Ionescu
Hi,
--- Maarten Bosma <maarten.paul(a)bosma.de> wrote:
> Maarten Bosma wrote:
> > I just want to point out that thunk/posix, trunk/os2, trunk/vms and
> > rosapps are still using the old build system.
>
> I forgot the bad thing, they can't use it if it's not there.
Fixing rosapps is on my TODO list for the next week.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
gvg(a)svn.reactos.com wrote:
>Revert some incorrect changes that were made during rbuild merge
>
>
>
>Updated files:
>trunk/reactos/tools/wrc/parser.y
>trunk/reactos/tools/wrc/y.tab.c
>trunk/reactos/tools/wrc/y.tab.h
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
Hi,
after this commit, I get the following build error:
[WRC] obj-i386\lib\cpl\appwiz\appwiz.coff
lib\\cpl\\appwiz\\/Cz.rc:11:41: Error: parse error
_make: *** [obj-i386\lib\cpl\appwiz\appwiz.coff] Error 1
- Hartmut
Hi,
we're stright aproaching a new release.
Or at first: A branch.
What about the version number? As far as I followed the discussions, 0.3
is still away :-( .
And how about our new build system. Is it successfully running?
I for my part would feel more comfortable if the next
intermediate-release would still use the old build system.
`Remove two file that are not need any longer
fix some compilings warings' <==
--- Ge van Geldorp <gvg(a)reactos.com> a écrit:
> > From: greatlrd(a)svn.reactos.com
> >
> > Updated files:
> > trunk/reactos/lib/cabinet/cabextract.c
> > trunk/reactos/lib/cabinet/cabinet_main.c
>
> What's the purpose of the changes you made to these two files?
>
> Gé van Geldorp.
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
> From: greatlrd(a)svn.reactos.com
>
> Updated files:
> trunk/reactos/lib/cabinet/cabextract.c
> trunk/reactos/lib/cabinet/cabinet_main.c
What's the purpose of the changes you made to these two files?
Gé van Geldorp.
Hi,
Here is my beef with rbuild. I can't fix most of these as I don't have
the skills/knowledge of rbuild.
1) Project link flags are applied at the end of the command line...this
makes -Wl optimization flags not work.
2) DBG = 0 and GCC 4 creates a load of new warnings that weren't there
before. For example, I can't build ntoskrnl anymore. This is because
it's detecting "uninitialized variables" which are actually being
initalized by the macros themselves (see mm/pe.c and elf.inc.h). This
did not happen before rbuild.
3) Strip isn't being executed for dbg = 0 anymore... I can add it but I
have no idea how to make it dbg = 0 only.
Not sure:
4) Is the OPTIMIZED envirovar still taken into account? I didn't seem to
see so.
Best regards,
Alex Ionescu
Hi.
I believe the new build system is ready to replace the current build system in trunk. Unless there are objections, I plan on merging
the branch to trunk in the weekend of 27 - 29 of may.
I'd like to take the opportunity to thank everyone that helped make this possible - especially Royce Mitchell III, Ge van Geldorp,
and Steven Edwards.
It would be nice if you could checkout the branch and check that the features you can't live without are still there so we can have
them ready before the merge. If you have major new feature requests that are not essential, I'd like to put them on hold until after
the merge. To checkout the branch do a:
svn co svn://svn.reactos.com/branches/xmlbuildsystem/reactos
For a list of environment variables that controls the build see:
http://svn.reactos.com/viewcvs/*checkout*/branches/xmlbuildsystem/reactos/M…
For more technical information see:
http://svn.reactos.com/viewcvs/*checkout*/branches/xmlbuildsystem/reactos/t…
This is not a 100% solution to our dependency problems though. There can still be corner-cases where it is needed to manually clean
some files, but it will be needed a lot less than today. Also in order to have acceptable performance, we cannot check dependencies
on every included file on each make invocation. Therefore, this is currently only checked each time the automatically generated
makefile (makefile.auto) is regenerated. Makefile.auto is regenerated each time a build system file (*.xml) is modified. If you need
to check the dependencies on files not specified in the build system files "automatic dependencies", then delete makefile.auto and
run make again.
Casper
navaraf(a)svn.reactos.com wrote:
>Use W32API.
>
>
>Updated files:
>trunk/reactos/drivers/net/npf/Makefile
>trunk/reactos/drivers/net/npf/dump.c
>trunk/reactos/drivers/net/npf/jitter.c
>trunk/reactos/drivers/net/npf/openclos.c
>trunk/reactos/drivers/net/npf/packet.c
>trunk/reactos/drivers/net/npf/packet.h
>trunk/reactos/drivers/net/npf/read.c
>trunk/reactos/drivers/net/npf/win_bpf.h
>trunk/reactos/drivers/net/npf/write.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
This breaks the dbg=0 build because of the ASSERT macro in winddk.h.
Best regards,
Alex Ionescu
navaraf(a)svn.reactos.com wrote:
>Bye, bye "include/net/" directory...
>
>
>Deleted files:
>trunk/reactos/include/net/
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
This breaks the build because lib/packet can't find the net include
files anymore.
Best regards,
Alex Ionescu
greatlrd(a)svn.reactos.com wrote:
> VBE driver never write which reslutions it should use as defualt
> therefor the change resultions did not working on bootcd
> do not remove this settings. from the reg.
> Thanks
>
> >
> Updated files:
> trunk/reactos/bootdata/hivesys.inf
>
This is already possible in the "hiveinst.file"
It should be only in one place
Regards
Gge
--- Robert K�pferl <rob(a)koepferl.de> wrote:
> we're stright aproaching a new release.
> Or at first: A branch.
> What about the version number? As far as I followed the discussions, 0.3
> is still away :-( .
>
> And how about our new build system. Is it successfully running?
> I for my part would feel more comfortable if the next
> intermediate-release would still use the old build system.
I would rather wait till Casper merges rbuild and we get it stable then tag a release. There is no
point in stablising the tree to just break it again in another week or two.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
Hi,
have problems to compile revison 15501. See below:
D:\home\willaxt\Entwicklung\ROS\src\reactos>make
crt: [DEPENDS] wine/.cppexcept.d
crt: [DEPENDS] wine/.cpp.d
crt: [CC] wine/cpp.c
crt: [CC] wine/cppexcept.c
crt: [AR] ../../dk/w32/lib/libcrt.a
freeldr: Tools are up to date.
freeldr: Tools are up to date.
===================================================== Assembling fat
===================================================== Assembling fat32
freeldr: Compiling mm/mm
freeldr: Compiling freeldr
freeldr: LINKING freeldr.sys
freeldr: LINKING setupldr.sys
freeldr: Make ALL done.
ntoskrnl: [DEPENDS] ob/.object.d
ntoskrnl: [CC] kd/kdinit.c
kd/kdinit.c:24: warning: initialization from incompatible pointer type
kd/kdinit.c:25: warning: initialization from incompatible pointer type
kd/kdinit.c:26: warning: initialization from incompatible pointer type
make[1]: *** [kd/kdinit.o] Error 1
make: *** [ntoskrnl] Error 2
D:\home\willaxt\Entwicklung\ROS\src\reactos>gcc -v
Reading specs from
D:/home/willaxt/Entwicklung/ROS/tool/MinGW/bin/../lib/gcc-lib
/mingw32/3.3.1/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable
-languages=c,c++,f77,objc,ada,java --disable-win32-registry --disable-shared
--e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x
--enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchroniz
ation
Thread model: win32
gcc version 3.3.1 (mingw special 20030804-1)
Did a complete new check out before. Could this be a compiler problem. Am I
using the right gcc version.
Thanks for help,
Theo
-------------------------------------------
Dipl.-Inf. (FH) Theodor Willax, Moosburg
http://www.willax-online.de
-------------------------------------------
_________________________________________________________________
So einfach geht das. MSN Toolbar mit Pop-up-Blocker. http://toolbar.msn.de/
Jetzt kostenlos downloaden und gut ist!
Hi,
Dynamic IP is not working actually for some unknown reason in my Ros
real hardware as dhcp DISCSCOVERmessage sent to dhcp server (my router)
by dhcp client has no reply ( noDHCPOFFER received in Ros)
This configuration is working fine in window but it is broken in my box
( don't know why it is broken but this happened already once ) .
As a alternative solution I setup Hivesys.inf for static IP and I got
the same dialog problem between dhpcp client and dhcp server .
=> the dhpc client service should not sent a DHCPDISCOVER message to the
dhcp
server if the IP address is static in Hivesys.inf ( so different of
"0.0.0.0")
=> The Ip address setup in Hivesys.ing must be taken into account in
that case.
I have created the Bug 639 for this issue
The test has been done with svn 15447
Regards
Gge
ion(a)svn.reactos.com wrote:
>Nonpaged Pool Liberation Day: Allow PagedPool to be used earlier, allow fast mutex to be used earlier on debug builds. Allocate all Se stuff from PagedPool, set the right object types to use paged pool, allocate all strings from paged pool, allocate PE sections from paged pool, and a bunch of other things which should, imo, be in paged pool. If anyone has any contradicting proof, let me know...until then, enjoy ~4-6MB more NonPagedPool
>
>
>
>
Hi,
I don't like the exchange from NonPagedPool to PagePool at the current
state of ros. There are two reasons:
A) The allocation of paged pool is very slowly compared with the non
paged pool allocation.
B) Since the change to the new object type structures, ros has a big
memory leakage in the memory (pool) allocation/deallocation of objects.
For the non paged pool, there exist some debug functions to find the
problem. The paged pool doesn't implement anything to find such problems.
- Hartmut
Hi Jason,
--- Jason Filby <jason.filby(a)gmail.com> wrote:
> Vizzini has officially stepped down from the kernel coordinator
> position. It's a pity that legalities and the nature of his business
> have put him in this position. I've expressed our thanks for his input
> and contributions to the project to Vizzini.
Thats sad to hear. We hope to see you again soon Vizzini.
> The kernel coordinator position will be up for vote for nominiated
> candidates. This will only happen after the UI team has settled.
Can we go ahead and start the nomination process and discussion now? There are a few people
that would be nice to see in this role, Filip, Hartmut, Alex, James, Hpoussin, Art, did I forget
anyone else? I would like to hear from each of them on if they would even want the job?
I am leaning towards Alex currently for my nomination because he has the most time to focus on the
kernel and has shown a lot of initiative though I don't always agree with his development and
research methods so someone else could get my nomination and or vote.
> In case you're wondering, the project coordinator position, which I've
> been sitting on for around 7/8 years now, will also be up for vote in
> the near future. This will only happen once we've nailed down a
> constitution for the project (and no, I'm not leaving the project,
> just opening things up).
Well lets get moving. Not that I want to see you gone or anything =) but your
we do need to move forward with this and I need to get some real business plans
together for the foundation stuff. BTW I am taking vacation for the next few days
from my day job and one of the things on my TODO list is to talk to the Legal people
about the trademark stuff again.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
mbosma(a)svn.reactos.com wrote:
>PackageManager
>
>
>Updated files:
>trunk/rosapps/packmgr/lib/options.cpp
>
>_______________________________________________
>
>
It would be nice if your commit messages had more...substance to them. =)
Best regards,
Alex Ionescu
Hi,
--- Jakob Eriksson <jakov(a)vmlinux.org> wrote:
> This is a known trouble with Windows programs too.
> There is icmp.dll, check out: http://www.sockets.com/ms_icmp.htm
This dll is depreacated though we have a copy of the implementation from Wine in our tree if
anyone wants to look at it.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
>Implement sub-allocation of small requests
>
>
>
>Updated files:
>trunk/reactos/boot/freeldr/freeldr/freeldr.c
>trunk/reactos/boot/freeldr/freeldr/mm/mm.c
>
>_
>
Ge,
After our changes I can now boot a network-ready (with DHCP + FTP
working) console-mode ROS with only 14MB of physical memory. I suspect
that after the OB leak is fixed this number will go down. My goal is 12MB.
There are also dozens of bugs in the paging code which someone has to fix.
Best regards,
Alex Ionescu
Hi,
--- Jason Filby <jason.filby(a)gmail.com> wrote:
> We need to vote on the UI Coordinator Vote. This will take 2 weeks
> according to our voting rules and only committers may participate. If
> you're not listed as a committer but participate in the project in an
> important way (testing/web work) then talk to an existing committer to
> get a recommendation.
I don't know who all has names in the race but my vote would be for Fireball. He has done quite a
lot of work helping on translation and international issues in ReactOS and I think with the
Russian Translation of the website and been helping others to translate ReactOS in to thier native
language.
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Hi Royce,
--- Royce Mitchell III <royce3(a)ev1.net> wrote:
> I don't think anybody would agree to me taking it on, my ability to
> contribute seems to come and go, and we need somebody who's going to be
> around more often than not.
Thats the only reason I didn't put your name on my list, not because of any lack for faith in your
ability and leadership.
My leaning still goes to Alex for his knowledge on the kernel. He and I have discussed what I view
to be attitude and professionalism (which I think we can agree most of us on IRC lack sometimes)
that the Kernel Cordinator needs to have. Because of the voting system we have some have also
suggested just not having a KC but I don't really think this is a good idea because sometimes we
need a point person to send patches to, direct media and new developer questions, and settle
disputes that cannot be fixed via voting.
Thanks
Steven
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
I think this is a very good idea.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi All,
This may not be related to a problem I'm having. I can not load cromwell
uhci driver. Ne2000 does load but unable to ping anything out side the box.
Both share irq 0xb or 11. I noticed we have apic and ioapic in 'mp'. How hard
would it be to port them over to 'up' for supporting uniprocessor. I could
try but the group mood ATM is fairly poor. Other words I would not like to
piss off anyone.
Using APIC would fix interrupt sharing problems and expand Ros to a higher
OS level.
Thanks,
James
ps I did disable hive loading for the ne2000 but since the board is still in
the box, I guess it's causing problems.
Here is the trace file from ncftp under ros... I hunted the error
down to something we are getting back from the system in sio/SWrite.c
WD
--
<kjk_hyperion> I have a penchant for mischief, property damage and stalking
<kjk_hyperion> and cheesecake, of course
Hi all
Vizzini has officially stepped down from the kernel coordinator
position. It's a pity that legalities and the nature of his business
have put him in this position. I've expressed our thanks for his input
and contributions to the project to Vizzini.
The kernel coordinator position will be up for vote for nominiated
candidates. This will only happen after the UI team has settled.
In case you're wondering, the project coordinator position, which I've
been sitting on for around 7/8 years now, will also be up for vote in
the near future. This will only happen once we've nailed down a
constitution for the project (and no, I'm not leaving the project,
just opening things up).
Regards
Jason
---------- Forwarded message ----------
From: Vizzini <vizzini(a)plasmic.com>
Date: May 24, 2005 4:32 AM
Subject: Status update
To: Jason Filby <jason.filby(a)gmail.com>
Cc: Ge van Geldorp <gvg(a)reactos.com>, ch(a)csh-consult.dk
Jason,
Due to a few unfortunate legal changes related to work that I can't
really avoid, I'm going to have to officially step down as the kernel
coordinator. I haven't had any time to work on the project lately
anyway, so it's probably better to just make it official. I've had a
blast working with you guys over the past couple of years, and I hope
to be able to contribute again some day.
I'll try to keep an eye on things in case there are questions that I
am needed for, but that doesn't seem to be happening too often.
Thanks again for letting me participate in the project. I'm sorry I
haven't been able to contribute more lately, and I wish I didn't have
to jump off the train completely, but such is life.
Thanks!
-Vizzini
Hi,
--- Ge van Geldorp <gvg(a)reactos.com> wrote:
> Is it just me or are more people uncomfortable by the public vote about
> people? I have no problems voting in public about issues, but I would prefer
> votes about people being emailed to a trusted impartial party who does the
> counting and only publishes the final tally. How do other projects handle
> this?
I've thought about this and I tend to agree. Like I said I am leaning towards one atm because I
know of only one that has any interest in the position but I want to hear from others about why
the would want to be or should be the KC. Once we have a list of people nominated perhaps it
should be secret ballot. Jason could even be our ballot box as he is currently 'cursed as the
cordinator' for the overall project.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
The results have been delayed for a day due to some last minute
questions by Emanuelle. The final results are now in:
YES, switch to a "Wine-Inspired/Compatible" Debug System, but using NT
Debugging facilities as channels: 7
UNDECIDED/HAS RESERVATIONS: 2
There were no "NO" answers, but both Eric and Hartmut expressed certain
disagreements. I've replied to them but have yet to receive a reply to
my arguments.
In any case, by a majority, the new system has been elected. We now need
developers to implement it :)
Best regards,
Alex Ionescu
Thanks al-Quaknaa!
On 5/24/05, Alli Quaknaa <alquaknaa(a)gmail.com> wrote:
> Hello Jason,
> I want to thank for all your work on ReactOS and on that project -
> it's great! Thanks also to everyone in the team.
> al-Quaknaa
>
Hi,
Our compatibility with w2k and XP sux! Here is a old psx.exe command and compare
it with the new windows 2k compatible one we have.
http://adsl-64-217-116-74.dsl.hstntx.swbell.net/ftp/pub/ReactOS/psx.exe
Just in case!
Looking at Nebbetts book Win NT/2k Native API Ref, our SYSTEM_PROCESS_INFORMATION
for w2k is not close at all! Where is LLLONG or LONGLONG PrivatePageCount?
What is funny, psx.exe uses NT4 structures! So how can we use w2k structs with
w2k and see if they really work?
Thanks,
James
hpoussin(a)svn.reactos.com wrote:
>Add ReactOS version at the start of the debug log
>
>
>Updated files:
>trunk/reactos/ntoskrnl/ke/main.c
>
>
>
Please revert:
1) KiSystemStartup is called for each CPU.
2) If you want to print something to the debug log, then add it into the
debug log's wrapper code or something. The version info is already
displayed on screen anyways..I don't get the point of this commit.
Best regards,
Alex Ionescu
hpoussin(a)svn.reactos.com wrote:
>Remove some debug messages at boot
>
>
>Updated files:
>trunk/reactos/ntoskrnl/mm/mminit.c
>
>_______________________________________________
>
>
Please revert, these are important.
Best regards,
Alex Ionescu
Hi,
Our compatibility with w2k and XP sux! Here is a old psx.exe command and compare
it with the new windows 2k compatible one we have.
Looking at Nebbetts book Win NT/2k Native API Ref, our SYSTEM_PROCESS_INFORMATION
for w2k is not close at all! Where is LLLONG or LONGLONG PrivatePageCount?
What is funny, psx.exe uses NT4 structures! So how can we use w2k structs with
w2k and see if they really work?
Thanks,
James
VOTING TOPIC: Switch to Wine Debug System, a run-time configurable Debug
System in which various debug modes can be used (TRACE, WARN, FIXME,
ERROR, etc). It would use DbgPrintEx along with Debug Filters (just like
on XP) which can be configured at run-time in the registry to set how
many of the messages to show. I believe the current WINE system has the
library doing all this checking, but it's possible they do actually use
the NT method. DbgPrintEx and filter states are currently unimplemented
in our ntdll/ntoskrnl, so they must be implemented. Additionally, these
Debug Messages would only be inserted into the code for a DBG build,
just like it is currently done now. Finally, using this system will
allow us to better share code with WINE.
PROS:
- Configurable debugging
- More versatility then just "Print Always" and "Print if
I remove NDEBUG"
- Better code sharing with WINE
- Will lead to the implementation of some DbgPrint
functions which NT Drivers are bound to use.
CONS:
- Requires developer time to switch to this system.
- Requires implementing some Kernel Functions.
VOTING TIME: 2 weeks. Results announced Monday 23rd at 5PM EST.
VOTING CHOICES:
- Yes! Get rid of DPRINT/DPRINT1 and
implement a run-time configurable Debug System with multiple verbose
levels, based on WINE syntax and Windows NT implementation.
- No! Stick with the current static,
compile-time DPRINT/DPRINT1 system.
VOTING OPEN TO: Due to the nature of this source-level change, voting is
opened only to developers.
Best regards,
Alex Ionescu
jimtabor(a)svn.reactos.com wrote:
> This is a CompareStringW hack to get (7z313.exe /Q) to install. If anyone else has a better way, go for it!
>
>
> Updated files:
> trunk/reactos/lib/kernel32/misc/lang.c
>
I managed to get it to install by c:\7z313 /Q, it worked. I'm guessing with the compare
string hack, it can be wrong, but? Anyone else with something better, I'm open!
Thanks,
James
hbirr(a)svn.reactos.com wrote:
>Don't interpret STATUS_PIPE_CONNECTED as error.
>
>
>
>Updated files:
>trunk/reactos/lib/kernel32/file/npipe.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
This is a hack, not a fix...
Best regards,
Alex Ionescu
Hi,
since the object manger rewrite all objects are allocated with the tag
'None'. I would like it if we can go back and add a tag for each object
type. This tag is used for the memory allocation of an object.
- Hartmut
Hi,
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
> Attention all ROS Developers who have not yet voted. There are 3 days
> remaining for this vote.
I have not been keeping tight track but it seems so far everyone is for it but Eric would like us
to add a extention like DPRINT1 support such as FIXME1 or WARN1 for messages we always want to see
or add on our own. It seems like we can just leave DPRINT1 and reduce its usage.
Also we all agree we need to figure out a way to be able to toggle Wine debug messages at runtime.
The only question remains about using it in kernel mode that Hartmut mentioned.
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Brandon Turner wrote:
> Yes, i can with 0.2.6(or any build you want to give me) after i get out
> of work today at 1pm EST.
>
Great thanks.
Tests need to be done on SVN HEAD.
If you don't have access to this, I can provide you with an iso.
I'll be in IRC later on tonight.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
I've been working on some code which involves timing and while I have been
getting good results in XP, I've not been getting the same results in ROS.
I'm unsure as to whether this is due to missing functionality in ROS, or the
fact that I'm using an emulator.
If I put together a few tests researching different timing methods, could
someone running ROS on real hardware run the tests for me, as I don't have
access to machine I can run them one.
Thanks,
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Channel rule #2: Congrats to Art !
Cordialement,
Usurp(aka Sylvain PETREOLLE)
Service de Production & d'Exploitation Informatique
GEFCO - #DMIT/DATO/PSI/PEI
Mail : <mailto:exploit@gefco.fr>
Tel : 01.49.05.29.29
-----Message d'origine-----
De : arty(a)svn.reactos.com [mailto:arty@svn.reactos.com]
Envoyé : vendredi 20 mai 2005 10:07
À : ros-svn(a)reactos.com
Objet : [ros-svn] [arty] 15429: Turned on -Werror
Turned on -Werror
Propogate AdapterBinding rather than LogicalAdapter or MiniportBlock in
places
where we handle a request since we might need the protocol that did the
request
later on, get rid of LogicalAdapter completely as according to Filip, it's
never needed.
Also, remove the Packet context hack in send complete if possible as this is
now unnecessary (we now send all needed information in the work item
instead).
MiniQueueWorkItem, MiniDequeueWorkItem and MiniDoRequest were all changed to
take an AdapterBinding.
Added MiniRequestComplete, which handles a request complete.
Fixed hang in ipconfig and the tcpip control panel.
Updated files:
trunk/reactos/drivers/net/ndis/Makefile
trunk/reactos/drivers/net/ndis/include/miniport.h
trunk/reactos/drivers/net/ndis/include/ndissys.h
trunk/reactos/drivers/net/ndis/ndis/miniport.c
trunk/reactos/drivers/net/ndis/ndis/protocol.c
_______________________________________________
Ros-svn mailing list
Ros-svn(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-svn
----------------------------------------------------------------------------
Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels
et sont exclusivement destinés à l'usage de la personne à laquelle ils sont
adressés. Tout point de vue ou toute opinion contenus dans ce message
expriment la pensée personnelle de leur auteur et ne représentent pas
nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas
la personne à laquelle ce message est destiné, veuillez noter que vous avez
reçu cet e-mail par erreur et qu'il vous est strictement interdit
d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message.
Si vous avez reçu ce message par erreur, merci de contacter la personne qui
vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO
déclinent toute responsabilité en cas d'altération, de modification,
d'édition, de diffusion sans autorisation de ce message ou en cas
d'affection de ce message par un virus.
This message and any attachments (the "message") are confidential and
intended solely for the use of the individual to whom they are addressed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of the GEFCO Group of Companies. If you are not
the intended recipient, be advised that you have received this email in
error and that any use, dissemination, forwarding, printing, or copying of
this message is strictly prohibited. If you have received this message in
error please contact the sender and delete the message immediately. The
GEFCO Group of Companies shall not be liable for the message if altered,
changed, falsified, edited, diffused without authorization or affected by
any virus.
----------------------------------------------------------------------------
Which ini file?
> -----Original Message-----
> From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of
> Phreak(a)svn.reactos.com
> Sent: 20. maj 2005 04:22
> To: ros-svn(a)reactos.com
> Subject: [ros-svn] [Phreak] 15423: Removed invalid . from path in thisusetup ini file as a
> temporary fix. Next step is to removethe darn ini file entirely
>
> Removed invalid . from path in this usetup ini file as a temporary fix. Next step is to remove the
> darn ini file entirely
>
>
> Updated files:
> trunk/reactos/bootdata/packages/reactos.dff
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
Hi,
I'm not able to install reactos from the current svn with the bootcd.
Usetup and the second stage setup works. After the next reboot, I get
only a message box with 'Userint failed to start the shell!'. If I
revert the changes from 15403 (using memory mapped files), I can
install reactos.
- Hartmut
hbirr(a)svn.reactos.com wrote:
>- Reference the file object in IopSecurityFile.
>- Don't set FO_DIRECT_DEVICE_OPEN in IoCreateStreamFileObject.
>- Disabled the setting of IRP_NOCACHE, because vfat cannot handle cached and non cached requests for the same file.
>- Set the correct device object in NtWriteFile.
>
>
>
>
>
>
Hi,
This change breaks usetup. As I said, IoCreateStreamFileObject must be
left with the current hack intact.
Best regards,
Alex Ionescu
About a week or two ago usetup took about 20 seconds on my system under
qemu to copy over the installation files. I thought even that seemed a
bit slow, so I started rewriting the code to use memory mapped files to
see if I could speed it up. Now that I finished with it, I noticed that
the current code in the repository now takes just over 90 seconds to
install the files, which my changes reduce back down to 20 seconds.
Does anyone have any idea about what revision this huge slowdown was
introduced in? I'll try and figure out the problem tonight but it would
help if someone could point me towards the vicinity of it now so I don't
have to spend time looking when I get home.
I'd like to get the normal code back to it's former 20 second install
area so I can get a good comparison with my new code. I'd be thrilled
if it then could get the install times down to 10 seconds.
Just recently, (cd "Program Files") has stopped working. It works
without the quotes, but when you tab complete the directory name, it
quotes it for you automatically. Anyone touch this recently?
WD
--
"<arty> the tree was touched a lot recently"
Thanks to Alex and Arty! 15407 & 15408 fix the problems I was seeing
with ftp. Please check your networking apps again!
WD
--
"<arty> the tree was touched a lot recently"
The changes in this revision broke building, I get this:
ntoskrnl: [CC] io/pnpmgr.c
io/pnpmgr.c: In function `IoGetDeviceProperty':
io/pnpmgr.c:63: warning: 'Data' might be used uninitialized in this function
mingw32-make[1]: *** [io/pnpmgr.o] Error 1
mingw32-make: *** [ntoskrnl] Error 2
Vit Herman wrote:
> So my question is: what is needed to get cross-compilation
> enviroment capable of building ReactOS on linux?
Here is an install script for 3.4.1, from Casper's site.
http://reactos.csh-consult.dk/download.php?id=13
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
I'm working on a list of things to test ReactOS with, and I already
have a good list of networking apps to try. I am interested in what
others use for personal "regression tests", particularly non-network
apps. I would like to make a comprehensive list of manual regression
tests to use in combination with programmatic ones.
Any info on our programmatic regression testing would be useful also.
Some things I scribbled down:
Changing the wallpaper
Ros on ros compilation
rosperf
I'm not including "Installing from the bootcd/running the livecd"
since alot of people do that anyway.
Thanks!
WD
--
"<arty> the tree was touched a lot recently"
I run though the first stage installer (formatting the disk) and after
it asks where I want to install freeldr (I choose MBR) ReactOS then
bugchecks:
(cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in
remaining path: "\Hardware
Profiles\Current\System\CurrentControlSet\Services\vmx_svga\Device0"!)
(cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in
remaining path: "\Hardware
Profiles\Current\System\CurrentControlSet\Services\vmx_svga"!)
(cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in
remaining path: "\Hardware
Profiles\Current\System\CurrentControlSet\Services"!)
(cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in
remaining path: "\Hardware
Profiles\Current\System\CurrentControlSet"!)
(cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in
remaining path: "\Hardware Profiles\Current\System"!)
(cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in
remaining path: "\Hardware Profiles\Current"!)
(cm/ntfunc.c:383) NtCreateKey() doesn't create trees! (found '\' in
remaining path: "\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00\0000"!)
(bootsup.c:1760) System path: '\Device\Harddisk0\Partition1'
(bootsup.c:1966) No or unknown boot loader found
(bootsup.c:1974) Copy: \Device\CdRom0\loader\freeldr.sys ==>
\Device\Harddisk0\Partition1\freeldr.sys
(bootsup.c:1989) Copy: \Device\CdRom0\loader\freeldr.sys ==>
\Device\Harddisk0\Partition1\freeldr.ini
(inicache.c:1037) BufferSize: 694
(bootsup.c:2003) Save bootsector: \Device\Harddisk0\Partition1 ==>
\Device\Harddisk0\Partition1\bootsect.old
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0x138 could not be read: Page not present.
kdb:> bt
Eip:
<vfatfs.sys:b592 (rw.c:572 (VfatRead))>
Frames:
<vfatfs.sys:d1f4 (misc.c:110 (VfatDispatchRequest))>
<vfatfs.sys:d3ee (misc.c:168 (VfatBuildRequest))>
<ntoskrnl.exe:4c898>
<ntoskrnl.exe:4c810>
<ntoskrnl.exe:487bf>
<ntoskrnl.exe:36d2>
<smss.exe:19c3>
<smss.exe:426f>
<smss.exe:16f18>
<smss.exe:17623>
<deadbeef>
kdb:>
Thanks to Alex for showing me how to enable serial output for the bootcd!
WD
--
"<arty> the tree was touched a lot recently"
Hi
Few days ago, I did my check of the state of ReactOS. I was surprised by
the progress made and decided to do some hacking with it. So I did a SVN
checkout of the source tree and wanted to build it, BUT! I realized that
cross-compiling ReactOS on linux is not as easy as I thought. So my
question is: what is needed to get cross-compilation enviroment capable
of building ReactOS on linux? I don't have any Windows box here and I
must admit I don't like the idea of having one either.
If there's anybody hacking ReactOS on Linux, I would apreciate his help.
I would personaly love to see some information about cross-compiling
on the website - it's really concise on this topic :(
Thanks for your help
Vit Herman
Hi,
if I browse the repository on svn.reactos.com, I see for
trunk/reactos/subsys/system/expand an old version and not all files. I'm
missing En.rc, expand.rc and resource.h. I get this files with a
checkout or an update. I've merged the trunk to a clean source tree of
the cache_mangeger_rewrite branch on my disk and committed the changes.
Exactly this three files wasn't committed to the branch, but they are in
my tree.
- Hartmut
hbirr(a)svn.reactos.com wrote:
>
>
> Deleted files:
> branches/cache_manager_rewrite/reactos/lib/msgina/
Just out of curiosity, what's that deleting+adding for?
Best Regards,
Thomas
Hi!
A patch, committed within the last two weeks, broke the named pipe
filesystem driver. The result is the message:
service/sctrl.c:305 Pipe read failed
The error code is ERROR_BROKEN_PIPE.
This bug keeps user-mode services from starting up. I assume the bug is
caused by one on the patches to ntoskrnls IO code because npfs has not
been touched for a few more weeks.
Please fix this bug as soon as possible as it keeps me from working on
PnP and RPC!
Regards,
Eric
David Johnson wrote:
> I asked too. No reply also.
> What gives?
>
> On 5/17/05, Fero Vlkolinsky <f.vlkolinsky(a)alcatel.sk> wrote:
> > Hi,
> >
> > I've read that Alex Ionescu wanted to start JANITOR project for reactOS.
I'd like to join but he didn't reply my > mail. So is this
> > project alive or is it abandoned completely?
> >
> > Fero
It's been put on hold for a while until Alex finishes school, (and winsock2,
and object manager and .... ) heh.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Hi,
I've read that Alex Ionescu wanted to start JANITOR project for reactOS. I'd like to join but he didn't reply my mail. So is this
project alive or is it abandoned completely?
Fero
Hi all,
Does anyone know if MingW packs structures by default (as I think Borland
does),
or do I need to declare #pragma pack(1) ?
Thanks,
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Hi all
There's interest in forming an interface team, and I think it's worth
exploring. This team would be responsible for all visual styling that
goes on in the project. This includes ReactOS UI design and the look &
feel of the website.
So far both mf (as known on IRC, and has come up with most of our
current icons in ReactOS) and Mikko Tikkanen (has done a great mock-up
for the site: http://devnet.dnsalias.net/guidesign/web_mockup.jpg)
have shown interest in heading this team. If anyone else wants to
throw their hat into the ring - feel free to do so.
It'll probably come down to a vote - but first if the respective
people could tell everyone more about themselves and perhaps the
related UI experience they have.
Regards
Jason
[CC] dinput_main.c
[CC] joystick_linux.c
[CC] joystick_linuxinput.c
[CC] keyboard.c
keyboard.c:43:1: warning: "LLKHF_EXTENDED" redefined
In file included from ../../include/wine/winuser.h:10,
from keyboard.c:30:
../../w32api/include/winuser.h:2150:1: warning: this is the location of
the prev
ious definition
keyboard.c:46:1: warning: "LLKHF_UP" redefined
../../w32api/include/winuser.h:2153:1: warning: this is the location of
the prev
ious definition
[CC] mouse.c
mouse.c:49: error: conflicting types for 'MSLLHOOKSTRUCT'
../../w32api/include/winuser.h:3076: error: previous declaration of
'MSLLHOOKSTR
UCT' was here
mouse.c:49: error: conflicting types for 'PMSLLHOOKSTRUCT'
../../w32api/include/winuser.h:3076: error: previous declaration of
'PMSLLHOOKST
RUCT' was here
make[1]: *** [mouse.o] Error 1
make: *** [dinput] Error 2
E:\src\ros\trunk\reactos>
Hi,
--- Jason Filby <jason.filby(a)gmail.com> wrote:
, and has come up with most of our
> current icons in ReactOS) and Mikko Tikkanen (has done a great mock-up
> for the site: http://devnet.dnsalias.net/guidesign/web_mockup.jpg)
I love that site design. That is how reactos.org should look.
Thanks
Steven
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
I was thinking about the security policy and NTFS partitions, I really like this function, but this is only availible on NTFS, but why not make the FAT driver head the policies and make it work as NTFS?
Of course it's really easy to boot from a DOS disk and be able to read/write any file, but being able to set access policys on a home-computer/network is a real help for an administrator. It doesn't stop a hacker, but children and wifes (some of them anyway).
Microsoft isn't interested in such a driver because they want everyone to run NTFS, but we don't have such preference, we are interested in the best function not our habitat.
Yours sincerely,
Jaix Bly
Its now fixed, please update.
--- Hartmut Birr <hartmut.birr(a)gmx.de> a écrit:
> Hi,
>
> I'm not able to compile win32k.
>
> - Hartmut
>
> M:\Sandbox\ros_work\reactos>_make win32k
> win32k: [DEPENDS] .w32k.d
> win32k: [PCH] w32k.h
> In file included from w32k.h:21:
> ../../ntoskrnl/include/internal/ob.h:41: error: syntax error before
> "OB_DUMP_METHOD"
> ../../ntoskrnl/include/internal/ob.h:41: warning: no semicolon at end of
> struct or union
> ../../ntoskrnl/include/internal/ob.h:42: warning: type defaults to `int'
> in declaration of `OpenProcedure'
> ../../ntoskrnl/include/internal/ob.h:42: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:43: error: syntax error before
> "CloseProcedure"
> ../../ntoskrnl/include/internal/ob.h:43: warning: type defaults to `int'
> in declaration of `CloseProcedure'
> ../../ntoskrnl/include/internal/ob.h:43: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:44: error: syntax error before
> "DeleteProcedure"
> ../../ntoskrnl/include/internal/ob.h:44: warning: type defaults to `int'
> in declaration of `DeleteProcedure'
> ../../ntoskrnl/include/internal/ob.h:44: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:45: error: syntax error before
> "ParseProcedure"
> ../../ntoskrnl/include/internal/ob.h:45: warning: type defaults to `int'
> in declaration of `ParseProcedure'
> ../../ntoskrnl/include/internal/ob.h:45: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:46: error: syntax error before
> "SecurityProcedure"
> ../../ntoskrnl/include/internal/ob.h:46: warning: type defaults to `int'
> in declaration of `SecurityProcedure'
> ../../ntoskrnl/include/internal/ob.h:46: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:47: error: syntax error before
> "QueryNameProcedure"
> ../../ntoskrnl/include/internal/ob.h:47: warning: type defaults to `int'
> in declaration of `QueryNameProcedure'
> ../../ntoskrnl/include/internal/ob.h:47: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:48: error: syntax error before
> "OkayToCloseProcedure"
> ../../ntoskrnl/include/internal/ob.h:48: warning: type defaults to `int'
> in declaration of `OkayToCloseProcedure'
> ../../ntoskrnl/include/internal/ob.h:48: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:49: warning: type defaults to `int'
> in declaration of `OBJECT_TYPE_INITIALIZER'
> ../../ntoskrnl/include/internal/ob.h:49: warning: type defaults to `int'
> in declaration of `POBJECT_TYPE_INITIALIZER'
> ../../ntoskrnl/include/internal/ob.h:49: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:62: error: syntax error before
> "OBJECT_TYPE_INITIALIZER"
> ../../ntoskrnl/include/internal/ob.h:62: warning: no semicolon at end of
> struct or union
> ../../ntoskrnl/include/internal/ob.h:65: error: syntax error before '}'
> token
> ../../ntoskrnl/include/internal/ob.h:65: warning: type defaults to `int'
> in declaration of `OBJECT_TYPE'
> ../../ntoskrnl/include/internal/ob.h:65: warning: data definition has no
> type or storage class
> ../../ntoskrnl/include/internal/ob.h:191: error: syntax error before
> "ObjectTypeInitializer"
> _make[1]: *** [w32k.h.gch] Error 1
> _make: *** [win32k] Error 2
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi,
I'm not able to compile win32k.
- Hartmut
M:\Sandbox\ros_work\reactos>_make win32k
win32k: [DEPENDS] .w32k.d
win32k: [PCH] w32k.h
In file included from w32k.h:21:
../../ntoskrnl/include/internal/ob.h:41: error: syntax error before
"OB_DUMP_METHOD"
../../ntoskrnl/include/internal/ob.h:41: warning: no semicolon at end of
struct or union
../../ntoskrnl/include/internal/ob.h:42: warning: type defaults to `int'
in declaration of `OpenProcedure'
../../ntoskrnl/include/internal/ob.h:42: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:43: error: syntax error before
"CloseProcedure"
../../ntoskrnl/include/internal/ob.h:43: warning: type defaults to `int'
in declaration of `CloseProcedure'
../../ntoskrnl/include/internal/ob.h:43: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:44: error: syntax error before
"DeleteProcedure"
../../ntoskrnl/include/internal/ob.h:44: warning: type defaults to `int'
in declaration of `DeleteProcedure'
../../ntoskrnl/include/internal/ob.h:44: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:45: error: syntax error before
"ParseProcedure"
../../ntoskrnl/include/internal/ob.h:45: warning: type defaults to `int'
in declaration of `ParseProcedure'
../../ntoskrnl/include/internal/ob.h:45: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:46: error: syntax error before
"SecurityProcedure"
../../ntoskrnl/include/internal/ob.h:46: warning: type defaults to `int'
in declaration of `SecurityProcedure'
../../ntoskrnl/include/internal/ob.h:46: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:47: error: syntax error before
"QueryNameProcedure"
../../ntoskrnl/include/internal/ob.h:47: warning: type defaults to `int'
in declaration of `QueryNameProcedure'
../../ntoskrnl/include/internal/ob.h:47: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:48: error: syntax error before
"OkayToCloseProcedure"
../../ntoskrnl/include/internal/ob.h:48: warning: type defaults to `int'
in declaration of `OkayToCloseProcedure'
../../ntoskrnl/include/internal/ob.h:48: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:49: warning: type defaults to `int'
in declaration of `OBJECT_TYPE_INITIALIZER'
../../ntoskrnl/include/internal/ob.h:49: warning: type defaults to `int'
in declaration of `POBJECT_TYPE_INITIALIZER'
../../ntoskrnl/include/internal/ob.h:49: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:62: error: syntax error before
"OBJECT_TYPE_INITIALIZER"
../../ntoskrnl/include/internal/ob.h:62: warning: no semicolon at end of
struct or union
../../ntoskrnl/include/internal/ob.h:65: error: syntax error before '}'
token
../../ntoskrnl/include/internal/ob.h:65: warning: type defaults to `int'
in declaration of `OBJECT_TYPE'
../../ntoskrnl/include/internal/ob.h:65: warning: data definition has no
type or storage class
../../ntoskrnl/include/internal/ob.h:191: error: syntax error before
"ObjectTypeInitializer"
_make[1]: *** [w32k.h.gch] Error 1
_make: *** [win32k] Error 2
>
> Well, in short, in the (now free downloadable) SFU 3.5 there is a NIS
> bridge, which exposes accounts and groups to NIS compliant machines.
> After installing SFU, your credentials management console shows a tab
> with tipical UNIX/POSIX attributes and files have an attrribute tab with
> rwxrvxrvx... It seems that the design of IFS subsystem assumes a
> superset of every known fs available about 1990.
>
Hmmm, yea. That's basicly what I think of the wohle thing.
It should be possible for an IFS or another part to do a 1:1 or a 100:90
mapping of rights and users <-> SIDs
In my opinion there'S nothing to it to limit the user-part of SIDs to
16-bit and cut out just that.
PS. My favorite is still JFS.
It has been prooved on OS/2 and OS/2 is our next relative. Its Src is
open(GPL) and it supports most of the features. Even reparse points can
be transparently implemented (EAs). I have nothing against s.o.
implementing NTFS, but I see many problems. So cut & off
Hi,
--- Robert K�pferl <rob(a)koepferl.de> wrote:
> Please, all, tell me, what are you insisting so much on so unimportand
> features like transparent encryption and transparent compression. In my
> eyes the first step is to have a FS which is better than FAT and allows
> ACLs+EA or xattr+posix-acls (NOTE these are mostly isomorphisms). Most
> people can pass on enc+compr at all. Some use it but they can wait or
> also pass on it until it can/will be implemented or not implemented.
> There exist ways to come around that. Even GPL. See 7zip and TrueCrypt.
> For my requirements TrueCrypt beats NTFS-EFS. So why bother.
If you want to extend vfat support which we have already done in our vfatfs.sys by adding support
for xbox fatx, then I propose we add Transactional Fat support. The idea was first proposed on
LKML and then later implement in WinCE.
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Hi!
greatlrd(a)svn.reactos.com wrote:
> Partiy implement long filename support
> example filefilefile.txt can store now with cdmake
> but not filefilefiles.txt have not check why it say not a iso9660 name
>
>
>
>
> Updated files:
> trunk/reactos/tools/cdmake/cdmake.c
>
>
Getting this;
cdmake.c: In function `parse_filename_into_dirrecord':
cdmake.c:621: warning: implicit declaration of function `itoa'
make[2]: *** [cdmake.o] Error 1
make[1]: *** [cdmake_target] Error 2
make: *** [tools] Error 2
Have fun!
James
Hi,
I'm not able to boot ros on my test machine. It seems that the crash is
related to rev 15255.
- Hartmut
...
DriverBase for aic78u2.sys: 809ed000
(io/driver.c:1204) Driver load failed, status (c0000001)
DriverBase for symc8xx.sys: 80a01000
(io/driver.c:1204) Driver load failed, status (c0000001)
DriverBase for fireport.sys: 80a0a000
(io/irp.c:397) Total allocates: 367
(io/irp.c:399) Alloc attempt on CPU list: 80d67e38
(io/irp.c:397) Total allocates: 368
(io/irp.c:399) Alloc attempt on CPU list: 80d67c80
(io/irp.c:397) Total allocates: 369
(io/irp.c:399) Alloc attempt on CPU list: 80d67ac8
(io/irp.c:397) Total allocates: 370
(io/irp.c:399) Alloc attempt on CPU list: 80c1c590
(io/irp.c:397) Total allocates: 371
(io/irp.c:399) Alloc attempt on CPU list: 00000000
(io/irp.c:406) Total misses: 17
(io/irp.c:412) Alloc attempt on SYS list: 80d6abd0
(io/irp.c:397) Total allocates: 372
(io/irp.c:399) Alloc attempt on CPU list: 00000000
(io/irp.c:406) Total misses: 18
(io/irp.c:412) Alloc attempt on SYS list: cccccccc
KeBugCheckWithTf at ke/catch.c:222
A problem has been detected and ReactOS has been shut down to prevent
damage to your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
KMODE_EXCEPTION_NOT_HANDLED
Technical information:
*** STOP: 0x0000001E (0xc0000005,0x800a3a68,0x00000000,0xcccccccc)
*** ntoskrnl.exe - Address 0x800a3a68 base at 0x80000000, DateStamp 0x0
Page Fault Exception: 14(2)
Processor: 0 CS:EIP 8:800a3a68 <ntoskrnl.exe:a3a68
(D:\DOKUME~1\hb\LOKALE~1\Temp/ccUdbaaa.s:35 (memset))>
cr2 cccccccc cr3 34000 Proc: 80c04ce0 Pid: 4 <System> Thrd: 80c057e0 Tid: 0
DS 10 ES 10 FS 30 GS 10
EAX: 00000000 EBX: 80d6b730 ECX: 00000025
EDX: 00000094 EBP: 800f0574 ESI: 80d685a8 ESP: 800f04fc
EDI: cccccccc EFLAGS: 00210212 kESP 800f04fc kernel stack base 800ee000
Frames:
<ntoskrnl.exe:93345 (mem.c:98 (RtlFillMemory))>
<ntoskrnl.exe:933de (mem.c:168 (RtlZeroMemory))>
<ntoskrnl.exe:48d94 (io/irp.c:1357 (IoInitializeIrp))>
<ntoskrnl.exe:47e4c (io/irp.c:450 (IoAllocateIrp))>
<ntoskrnl.exe:48199 (io/irp.c:643 (IoBuildDeviceIoControlRequest))>
<scsiport.sys:3071 (scsiport.c:1948 (SpiSendInquiry))>
<scsiport.sys:3448 (scsiport.c:2098 (SpiScanAdapter))>
<scsiport.sys:216f (scsiport.c:1118 (ScsiPortInitialize))>
<fireport.sys:736>
<ntoskrnl.exe:3ef6e (io/driver.c:563 (IopInitializeDriverModule))>
<800AAFCC>
<ntoskrnl.exe:3f8ea (io/driver.c:1267 (IopInitializeBootDrivers))>
<800AB926>
<800A915A>
<ntoskrnl.exe:10544 (ke/main.c:103 (KiSystemStartup))>
<800A77AA>
<0>
I readed somewhere in Internet thats is any way to run CygWin
applications like bash on WinE. How can I do it?
And what doesn't reactos have that's needed to run cygwin on ReactOS?
Hi all
Some feedback from Eugenia of osnews.com.
Cheers
Jason
---------- Forwarded message ----------
From: Eugenia Loli-Queru <eloli(a)hotmail.com>
Date: May 2, 2005 7:02 AM
Subject: reactos
To: jason.filby(a)gmail.com
I just downloaded the latest reactos and tried it with qemu 0.7. Some
points:
1. Most of the panels don't fit on VGA screens and so I can't apply
settings. It would be wise to design them as VGA-friendly.
2. I can't change the resolution and it seems you don't support qemu's
network adapter either?
3. Please provide some apps with the emulated OS (adding 10 more MBs is not
a big deal). I can't download anything atm as I don't have a browser or
internet access inside reactos and this limits my experience with it.
thx,
Eugenia
I just spent most of an hour resolving merge conflicts,
mostly due to our use of keywords. I think my time could
have been better spent on improving the build system.
Can we please avoid using keywords unless the information
needs to be compiled into ReactOS?
Casper
Steven Edwards wrote:
>
> The problem is that while Reiser4 is very extendable and and supports a
nice plugin API there is
> no reiser driver for Windows that we can use. There is already a ext2fsd
(3 of them actually) and
> we can extend it to support ext3 with very little work.
As a requirement of anything other than vfat is still quite some time in the
future, is it not worth contacting the Reiser team to see if we rally them
to build a Windows driver?
By the time we need to implement functionality which vfat can't support,
they may have been able to put something together.
If you don't ask, you don't get :)
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Hi Rick,
--- Rick Langschultz <rlangschultz(a)cox.net> wrote:
> If people want to implement NTFS so badly why not use something like
> ReiserFS4 for the actual fs, but write a VFS driver to be loaded to act like
> NTFS. Since ReiserFS supports permissions and things of that nature it
> should be interesting to see the result. Filesystem encryption could
> possibly be implemented for files or folders too.
The problem is that while Reiser4 is very extendable and and supports a nice plugin API there is
no reiser driver for Windows that we can use. There is already a ext2fsd (3 of them actually) and
we can extend it to support ext3 with very little work.
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Hi,
--- Phillip Susi <psusi(a)cfl.rr.com> wrote:
> How would you reconcile the two different sets of owner and access
> information associated with the file? For instance, if someone creates
> a file on the partition from Linux, then you mount it with ROS, who owns
> the file? Who has access to it? Linux would only place some
> meaningless uid and chmod mask in the inode, so how would ROS come up
> with a sensible security descriptor for the file when one does not
> already exist?
Windows would have this same problem with NTFS on Linux. If I am under Linux and make changes to
files and create files how does linux-NTFS assign the proper SID and such to the files? This has
been a long time problem that NTFS has with taking a drive from one Windows box to another. Its
the same situation and mostly pointless. 99% of new ReactOS are not going to care and the
resources we get from having a better filesystem now can be put in to developing a NTFS
replacement.
> These are the kinds of problems that make attempts for ReactOS to share
> a unix filesystem ( and vice versa ) kludgey at best.
If the ext2fsd supported ext3 journals there would be nothing wrong with using it. I mean hell
right now ReactOS does not have a security subsystem so this whole discussion is a moot point.
Unless you feel like implementing lsass =)
Thanks
Steven
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
weiden(a)svn.reactos.com wrote:
> Updated files:
> trunk/reactos/lib/cpl/intl/locale.c
Sorry, I forgot the commit message. the NULL termination character of
the string should be saved as well, so calculate the buffer size correctly.
Hi Rob,
--- Robert Shearman <rob(a)codeweavers.com> wrote:
> You can do it the same way Samba does it by using xattrs. It's a shame
> that so few ReactOS developers turned up to WineConf as the Samba team
> did a presentation on this.
Yes that has been my suggestion. In my mind most people wont upgrade from Windows to ReactOS as
they already have a Windows license so ReactOS like Linux wont have much need for NTFS. Right now
there is a ext2fsd that mostly works with ReactOS but currently it has some problems with ext3. I
am aware that you can do xattr support with ext2 and have suggested this to the ReactOS team.
Thanks
Steven
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
Hi Mike,
--- Mike Nordell <tamlin(a)algonet.se> wrote:
> Reparse points is a feature of NTFS I've myself used since over half a
> decade now. As I know I'm not alone using both junction points and volume
> mount points, I'd think scraping the barrel might be "somewhat" misleading.
I think Robs point is the same as mine. Right now 99% of the world does not care about those
features where they do care about the other 50% of the features ReactOS does not currently
implement.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
Hi:
Remember the another filesystem driver could be installed in WinNT as part of the ReactOS setup in those dual boot scenarios. Maybe WinNT could boot from that X filesystem too. You won't be using an NTFS partition or creating it and you won't need to create a different driver for NT since ROS driver should run ok on NT.
Regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Murphy, Ged (Bolton)
Sent: Wed 5/11/2005 10:22 AM
To: 'ReactOS Development List'
Subject: RE: [ros-dev] Security policy for FAT partition driver?
Jonathan Wilson wrote:
> Basicly, there are 2 kinds of users.
> There are those who have windows and and NTFS partition and want to access
> it from ROS. (perhaps dual boot ROS and win from the one NTFS partition
> ambie if that is something ROS can be made to do). These people can use
> ntfs.sys from MS since they have windows.
>
> Then there are those who dont have windows, dont have an existing NTFS
> partion and dont have a copy of ntfs.sys.
> Those people can use whatever other solution we come up with (ReactOS
> implementation of NTFS, some unix FS like ext/reiser etc or whatever else
> we come up with).
That seems to make perfect sense.
Why would anyone need/want to use NTFS if they don't need to access existing
NTFS drives?
If they do have existing NTFS drives, then as Jonathan says, they should
also have the driver from MS to access it.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hi:
Well that's right until you try to access an encrypted file system.
regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Mike Swanson
Sent: Tue 5/10/2005 6:30 PM
To: ReactOS Development List
Subject: Re: [ros-dev] Security policy for FAT partition driver?
Philip: Any filesystem is plenty insecure if you are accessing it via
a bootable CD-ROM or other such measures. Also, ext2 already has a
journal, it's called ext3.
--
Mike
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hello,
I am playing with DebugView from SysInternals and i noticed that ROS
KeBugChecks in NtOpenProccess (line 878):
if (ClientId->UniqueThread)
{
/* Get the Process */
if (ClientId->UniqueThread == (HANDLE)-1) KEBUGCHECK(0);
<===== HERE
DPRINT("Opening by Thread ID: %x\n", ClientId->UniqueThread);
Status = PsLookupProcessThreadByCid(ClientId,
&Process,
&Thread);
DPRINT("Found: %x\n", Process);
It looks like that UniqueThread holds value -1. I look in
NtCreateThread and it has CID handle creation implemented
(PsCreateCidHandle and friends ...)
I only get KeBugCheck with DebugView (another exes run properly). If
you force a false evaluation (for example: if
((ClientId->UniqueThread)&&(0))) NtOpenProcess does a LookUp by
proccess cid and DebugView run fine
Any idea?
It'd be interesting to see one develop a filesystem for ReactOS, but
AS a filesystem designed explicitly for the OS itself. It could be
called "ROSfs" or something similar.
--- "Murphy, Ged (Bolton)" <MurphyG(a)cmpbatteries.co.uk> wrote:
> I think what Boaz was talking about here was is the fact that the Samba team
> (tridge) are talking about porting Samba to the Windows environment for ROS.
> My (limited) understanding of this is it would be a 'real' emulation of
> cifs/netbt, not samba running in a unix environment via POSIX.
>
> Speak to Steven Edwards or KJK for more info as they were talking to Tridge.
Short term Samba and Samba-Tng are going to be ported to Mingw so they can run on Windows and
ReactOS. Long term there does need to be a intigration plan. I think we can wrap smbd in a dummy
Server service but I have not done much research on the intigration part yet. Right now I just
want to get the damn things built and sharing files. Samba is a lot more besides just the
filesharing module.....Its ms-rpc, network printer spooling, wins and network winlogin/Active
Directory, etc.....
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Phillip Susi
> > 2. I have not been to Wineconf-2005, but from the summery what I could
> > see is that one of the key notes was the Samba team. Now ReactOS is
> > going to use Samba right?
>
> No. ReactOS will not use Samba anymore than we use WINE, which is to
> say, we might borrow bits of code here and there, but as a whole, the
> project is radically different than what we need. Samba is a server
> that runs on Linux and emulates a lanman/cifs/whatever MS is calling it
> these days server. What ReactOS would need is a real implementation of
> the lanman server on an NT kernel, not a hacked emulation on top of posix.
I think what Boaz was talking about here was is the fact that the Samba team
(tridge) are talking about porting Samba to the Windows environment for ROS.
My (limited) understanding of this is it would be a 'real' emulation of
cifs/netbt, not samba running in a unix environment via POSIX.
Speak to Steven Edwards or KJK for more info as they were talking to Tridge.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Jonathan Wilson wrote:
> Basicly, there are 2 kinds of users.
> There are those who have windows and and NTFS partition and want to access
> it from ROS. (perhaps dual boot ROS and win from the one NTFS partition
> ambie if that is something ROS can be made to do). These people can use
> ntfs.sys from MS since they have windows.
>
> Then there are those who dont have windows, dont have an existing NTFS
> partion and dont have a copy of ntfs.sys.
> Those people can use whatever other solution we come up with (ReactOS
> implementation of NTFS, some unix FS like ext/reiser etc or whatever else
> we come up with).
That seems to make perfect sense.
Why would anyone need/want to use NTFS if they don't need to access existing
NTFS drives?
If they do have existing NTFS drives, then as Jonathan says, they should
also have the driver from MS to access it.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Mark Junker wrote:
> simply use ReiserFS 4 because it implements all (!) features that are
provided by NTFS.
That would be my choice of filesystem also.
I don't see a reason for trying to implement ext2/3 when we have ReiserFS at
our disposal.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
--- Casper Hornstrup <ch(a)csh-consult.dk> wrote:
> Probably, but they won't have the same casing as in the Platform SDK then.
Yes but Windows is case insensitive so matching the PSDK case is just a waste of time. Besides the
rest of the w32api is in lower case so anyone importing a project on mingw-linux already has to
adjust the case. If there are no objections I will change the GDIplus headers and the source for
the stub dll.
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Hi,
--- chorns(a)svn.reactos.com wrote:
> Re-add local w32api changes
> Added files:
> trunk/reactos/w32api/include/GdiPlus.h
This has bothered me for a while. Can we make the filenames all lowercase? Having mixed cases
causes a problem when people develop on Windows and don't check to make sure they have used the
correct case in source files resulting in broken builds of Linux developers.
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
I spent some time doing a mingw port of GCC4 lately and here's my
experimental mingw-special-reactos port for win32:
http://www.reactsoft.com/mingw-special-reactos-20050510.zip
The reactos tree fully compiles from rev. 15198 on and appears to work
fine. However, please read notes.txt inside the archive to get it to
work properly (default paths are messed up, so you have to set up three
environment variables).
Compiling reactos with it will produce quite a bunch of warnings, mostly
from 3rd party libraries (e.g. oskittcp, mesa32), the imported wine code
and explorer.
Best Regards,
Thomas
ion(a)svn.reactos.com wrote:
>Make the remaning code match the current formatting instead of being really ugly,
>
>and make some changes to IoCreateFileStreamObject (which is wrong anyways, since it's doing what *Lite should do)
>
>
>
This breaks usetup/vfat/whatever. I'll fix it until I have time to look
at the whole picture. (Well actually I'll add back the incorrect parts
of the code :P)
Best regards,
Alex Ionescu
Hi there,
It'd be very appreciated if some fellow with write access can commit
this patch.
It implements SeCreateAccessState, SeDeleteAccessState and
SeSetAccessStateGenericMapping.
It defines an opaque structure for _ACCESS_STATE too.
Best regards,
-Javier
Hi,
--- Thomas Weidenmueller <w3seek(a)reactos.com> wrote:
> If you know, why shouldn't he know? From what I understand the entire
> structure is opaque, so my guess is that the names are just guessed,
> based on the obviously known layout.
I googled for quite a while and found next to nothing about these functions or that structure. A
little birdy told me that a IDA lookup does not even show a third member.
Thanks
Steven
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
ion(a)svn.reactos.com wrote:
>Fix NtWriteFile: Get right Deviceobject, Use FileObject->FinalStatus, use FileObject-.CurrentByteOffset if ByteOffset == FILE_USER_FILE_POINTER_POSITION, add SEH, use right event requested access, set IRP_WRITE_OPERATION flag, add support for IRP_NOCACHE and add support for SL_WRITE_THROUGH if FO_WRITE_THROUGH is enabled.
>
>
>
>
Hey Steven, I don't know what happened but this commit added a bunch of
whitespaces back!? I don't know why, I already had updated to the latest
version. Anyways, please run your script again I guess. (on file.c)
Best regards,
Alex Ionescu
Hi,
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
> Nope, with Dbg Filter States we have the ability to create an unlimited
> number of "channels"
Is there a documented list somewhere of the channel names/numbers Microsoft uses for each dll? It
would be nice to have Wine and ReactOS match the Windows implementation.
Thanks
Steven
Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check it out!
http://discover.yahoo.com/
--- Hartmut Birr <hartmut.birr(a)gmx.de> wrote:
> Please split the voting for kernel mode and user mode components.
>
> KERNEL MODE: NO
Is there a problem with declairing a debugchannel for each subsystem in Ntoskrnl and using it? One
of the goals of using the Wine system is to have the ability to toggle debug messages at runtime.
Thanks
Steven
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
I would like to see a 0.2.7 release soon. 0.3.0 is getting closer
every day, but it's not there yet IMHO. On the other hand, we have
had lots of big patches from Mr. Ionescu (and others), major changes,
go in and appear to be stable since we have released 0.2.6. I would
like to see us have another release in this lull, instead of having a
release right after committing a pile of patches *right before* the
release like we did with 0.2.6.
I know it's been less than a month since 0.2.6, but my the time we
branch and do a couple RC's, it will have been over a month.
I just have this feeling that we miss some regressions from release to
release, since alot of us just use HEAD on a regular basis?
Just my $0.2US
WD
--
"<tinus_> and also win32k should be fixed up a bit"
ion(a)svn.reactos.com wrote:
>Change optimization settings for retail builds. Change to -Os for smaller executables which are not slower, and enable more advanced optimizations. funitatatime is already included by default in GCC 4.0. Strip debug info from retail builds, since we don't parse the symbols anyways. I hope these options don't break anything, they don't for me; Debugging is unaffected.
>
>
The direct result of this is that, for non-debug builds (which don't
support reading data from symbols anyways, not even during bugcheck),
the following data are now true:
1) ntoskrnl is 612kb on my system, down from 1.5MB
2) win32k is 316kb on my system, down from 800kb
3) taskmgr shows 6% idle cpu time, down from 9%
4) memory usage shows 32MB, down from 40MB+
5) total ISO size is now 12.5MB, down from 14.2MB.
Booting up the system to be much faster and everything is more
responsive, probably due to the smaller size and new optimizations.
Nothing has changed for DBG builds.
Best regards,
Alex Ionescu
hbirr(a)svn.reactos.com wrote:
>- Set the IOSB on error for async irp's with a sync FO (fix bug #609).
>
>
>
Clearly, the problem is that someone is reading the Iosb instead of
reading the FileObject->FinalStatus.
Do you know who is doing that? Fixing the caller would fix the bug,
instead of adding the hack into the IRP Code.
Thanks for the commit,
Best regards,
Alex Ionescu
> From: weiden(a)svn.reactos.com
>
> more fixes for GCC4
>
> Updated files:
> trunk/reactos/tools/wrc/lex.yy.c
Hmm, this is going to be a problem, lex.yy.c is a generated file.
Gé van Geldorp.
You will likely need to remove the w32api directory before you "svn up" next time.
Casper
> -----Original Message-----
> From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of
> chorns(a)svn.reactos.com
> Sent: 8. maj 2005 19:43
> To: ros-svn(a)reactos.com
> Subject: [ros-svn] [chorns] 15140: Delete old w32api
>
> Delete old w32api
>
>
> Deleted files:
> trunk/reactos/w32api/
You are really abusing the version control system here.
By not using a vendor import for the external project w32api, you make it much harder to keep local changes separate from the
non-local changes to w32api and thus complicating the synchronization of the two. This is what Gé is currently doing with the shared
wine code and eventually all external code should be imported this way to minimize maintenance.
By re-importing the data from trunk instead of merging it from trunk, you effectively screw up the versioning. When the time comes
to merge your changes to trunk, you cannot since there is no common history. The only way to get it to trunk is to use "svn delete"
and "svn copy" and thus you loose any changes made to include/ and w32api/ on trunk since you created the branch.
I'd suggest you read Gé's introduction at http://reactos.com/wiki/index.php/Using_code_from_other_projects and
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-4 and do it this way instead.
Casper
> -----Original Message-----
> From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of
> ion(a)svn.reactos.com
> Sent: 8. maj 2005 03:31
> To: ros-svn(a)reactos.com
> Subject: [ros-svn] [ion] 15097: Wipe out current includes to start fresh.
>
> Wipe out current includes to start fresh.
>
>
> Deleted files:
> branches/new_headers/reactos/include/
> branches/new_headers/reactos/w32api/
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
I just loaded reactos with svn 15089 , built during the night , and
networking is completely broken.
I cannot ping my dsl router ( request timeout )
Regards
Gerard
Copied from the archive because I will receive the mail in some hours:
>hbirr at svn.reactos.com wrote:
>>- Guard the copying to the IOSB.
>>- Do the main processing on success or if previous STATUS_PENDING was
returned.
>> Do not use some of the IRP and FO flags at this point.
>>
>>
>Ok, I was going to complain about this, but I realize that it must be
>used since defintely some parts of ROS don't work properly with those
>flags set.
It isn't possible to use the flags, because some functions are always
synchronous independently which flags are set. Ntoskrnl may set the
flags correctly, but a driver may possible not.
>>- Set all results before signaling the events.
>>- Signal the FO event previous the user event.
>>- Made the code a little bit shorter.
>>
>>
>>
>I like your changes and have no complaints, except that the signaling
>semantics of the File/User events should be different in the failure
>case (my "else" path). You've completely removed that path and thus
>changed the logic.
If the driver has returned STATUS_PENDING and completes the irp later
with an error, both events must be signaled, because two different
threads may waiting on this events. The IOSB must be also set. The apc
must be also deliver (I've tested this with the apc sample and some
modifications on windows). There is no difference between completing the
irp with and without an error if the driver has returned STATUS_PENDING.
- Hartmut
sedwards(a)svn.reactos.com wrote:
>remove trailing whitespace at end of lines
>
> *[truncated at 1000 lines; 37354 more skipped]*
Steven,
This patch is unacceptably large, and your commit message is way too
short to explain all the changes. Please revert the patch immediately
and work on a branch, submitting small patches at a time so that other
developers can review them. Also, formatting patches are prohibited, so
I don't think your patches can be accepted at all, even if in a branch.
Best regards,
Alex Ionescu
<If anyone did not notice the sarcasm, please shoot yourselves. Great
work Steven; I hoped you used an automated tool!>
hbirr(a)svn.reactos.com wrote:
> - initialize a user profile before loading syssetup.dll.
> - this makes it possible to install ros over an existing ros.
>
>
>
> Updated files:
> trunk/reactos/subsys/system/setup/makefile
> trunk/reactos/subsys/system/setup/setup.c
>
Harmut ,
Does this apply if Ros is started from a freeldr diskette ?
Regards
Gerard
Hi,
There are currently some files in ntoskrnl/rtl, lib/rtl, and /lib/crt
which are duplicated. Stuff like vsprintf, sprintf, etc.
I think they should be massaged into lib/string so that all the modules
can share the code instead of duplicating it THREE times(!).
Best regards,
Alex Ionescu
--- J M <open.proyects(a)gmail.com> a écrit:
> Hi list,
>
> I am having "problems" with debugging support. I have my build
> environment in Windows. I set up gcc/g++/nasm ok and i'm building last
> SVNs without any problem.
>
> I'd like to debug some code and i get problems here. I test vmware
> with the following results ...
>
> VMWare (config => KDB=1, DBG=1)
> ---------------------------------------
> * DEBUGPORT=COM1 BAUDRATE=115200 => CRASH, FREEZE!!!
> * DEBUGPORT=FILE => REBOOT
im getting the same problem with DEBUGPORT=FILE on real hardware.
no clue found at the moment.
>
> Can we debug ReactOS with VMWare ?
>
> How can i update the ReactOS files in a QEMU's .img file ?
mount it with winimage on windows,
and with the loopback under linux.
mount -o lo qemufile.img /mnt/ros_c
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi list,
I am having "problems" with debugging support. I have my build
environment in Windows. I set up gcc/g++/nasm ok and i'm building last
SVNs without any problem.
I'd like to debug some code and i get problems here. I test vmware
with the following results ...
VMWare (config => KDB=1, DBG=1)
---------------------------------------
* DEBUGPORT=COM1 BAUDRATE=115200 => CRASH, FREEZE!!!
* DEBUGPORT=FILE => REBOOT
Can we debug ReactOS with VMWare ?
How can i update the ReactOS files in a QEMU's .img file ?
Thanks in advance!
Hi,
since some time, I'm not able to install ros from the bootcd over an
existing ros. The first stage setup works perfect. The second boot hangs
after loading most of the drivers. The last line on the debug port comes
from framebuf.dll:
...
DriverBase for \??\E:\ReactOS\system32\win32k.sys: 9d62b000
DriverBase for \??\E:\ReactOS\system32\freetype.dll: 9d803000
DriverBase for \SystemRoot\System32\kbdgr.dll: 9d78f000
(ntuser/desktop.c:574) IntShellHookNotify: No desktop!
(ntuser/desktop.c:574) IntShellHookNotify: No desktop!
(ntuser/desktop.c:574) IntShellHookNotify: No desktop!
DriverBase for \SystemRoot\System32\framebuf.DLL: 9dfab000
Has anyone the same problem? The install works again, if I delete all
registry files from the existing installation. Usually I use the 'make
install' command to install ros over the network on my test machines.
- Hartmut
Hi,
I find the problem is caused by msys or by msys's make.exe, the command
line:
$(CABMAN) /C bootdata/packages/reactos.dff /L $(BOOTCD_DIR)/reactos /I
Will be expanded like this:
$(CABMAN) c:/ bootdata/packages/reactos.dff c:/msys/1.0/L
(BOOTCD_DIR)/reactos i:/
I don't know why. And when I use "mingw32-make bootcd", everything is ok.
And if we use cabman.exe in msys, the command line should like this:
$(CABMAN) //C bootdata/packages/reactos.dff //L $(BOOTCD_DIR)/reactos //I
It goes well.
-----邮件原件-----
发件人: ros-dev-bounces(a)reactos.com [mailto:ros-dev-bounces@reactos.com] 代
表 Hartmut Birr
发送时间: 2005年5月5日 19:32
收件人: ReactOS Development List
主题: Re: [ros-dev] about rules.mak, a small bug fixed
Your patch breaks compiling on windows without msys. I've commit a
different fix which will solve your problem. There does exist one
problem, it isn't possible to build the bootcd. There is somewhere a
'c:/..' on the path, which isn't correct within a simulated posix system
like msys.
- Hartmut
greatlrd(a)svn.reactos.com wrote:
> tinus
> implement MouseResolution setting
>
> Me (Magnus Olsen)
> remove old psuax drv from hiveinst.inf and add tinus mouse drv settings
> add MouseResolution setting to reg
>
>
>
>
> Updated files:
> trunk/reactos/bootdata/hiveinst.inf
> trunk/reactos/bootdata/hivesys.inf
> trunk/reactos/drivers/input/i8042prt/i8042prt.h
> trunk/reactos/drivers/input/i8042prt/mouse.c
>
The mouse is moving slowly in my machine.
What are the possible values for MouseResolution setting in Hivesys.inf
Regards
Gerard
weiden(a)svn.reactos.com wrote:
> - directly forward GetSecurityDescriptorLength to NTDLL.RtlLengthSecurityDescriptorguard dumping the stack trace to prevent infinite exception loopsguard dumping the stack trace to prevent infinite exception loops
my svn client somehow screwed up the message, it's supposed to be only
- directly forward GetSecurityDescriptorLength to
NTDLL.RtlLengthSecurityDescriptor
Best Regards,
Thomas
hbirr(a)svn.reactos.com wrote:
>- Free always the name string and the completion context in IopDeleteFile.
>
>
>Updated files:
>trunk/reactos/ntoskrnl/io/file.c
>
>
>
The lack of a Device Object signifies there is something REALLY wrong
with the file, and should be treated as invalid. It might not be wise to
do any further operations on it, since they probably already have been done.
Best regards,
Alex Ionescu
Mark Junker wrote:
> The build system seems to be sub-optimal <g>.
There is a new xml build system coming into place soon which is much better
than the current one.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
1) Assertion gets hit on:
Assertion PdoNameInfo->Name.Length failed at io/deviface.c:606
Entered debugger on embedded INT3 at 0x0008:0x80005813.
2) Cmd.exe outputs garbage.
3) DHCP crashes during boot.
Best regards,
Alex Ionescu
hbirr(a)svn.reactos.com wrote:
>- Guard the copying to the IOSB.
>- Do the main processing on success or if previous STATUS_PENDING was returned.
> Do not use some of the IRP and FO flags at this point.
>
>
Ok, I was going to complain about this, but I realize that it must be
used since defintely some parts of ROS don't work properly with those
flags set.
>- Set all results before signaling the events.
>- Signal the FO event previous the user event.
>- Made the code a little bit shorter.
>
>
>
I like your changes and have no complaints, except that the signaling
semantics of the File/User events should be different in the failure
case (my "else" path). You've completely removed that path and thus
changed the logic.
Best regards,
Alex Ionescu
When I compile reactos, I find a problem, my make report:
string: [DEPENDS] i386/.wcsrchr.d
/bin/sh.exe: ....toolsdepends.exe: command not found
make[1]: *** [i386/.wcsrchr.d] Error 127
make: *** [string] Error 2
I find the problem is that sh.exe ignored ��\��.
The command line is :
@gcc -Wall -Werror -D_DISABLE_TIDENTS -D__USE_W32API -fno-strict-aliasing
-O6 -
I. -I../../include -I../../w32api/include -pipe -march=i486 -D_M_IX86 -Os
-Wno-s
trict-aliasing -ftracer -momit-leaf-frame-pointer
-mpreferred-stack-boundary=2 -
funit-at-a-time -fweb -g -M i386/wcsrchr.s | ..\..\tools\depends.exe i386
i386/.
wcsrchr.d
And ��..\..\tools\depends.exe�� was changed into ��....tools\depends.exe��
by sh.exe
My msys is MSYS-1.0.10
So I made a patch on rules.mak , and the problem solved .
F:\SVNReactos\reactos>svn diff rules.mak
Index: rules.mak
===================================================================
--- rules.mak (修订版 14957�?
+++ rules.mak (工作拷贝)
@@ -122,7 +122,7 @@
export NASM_CMD = $(Q)nasmw
export DOSCLI = yes
export FLOPPY_DIR = A:
-export SEP := \$(EMPTY_VAR)
+export SEP := /$(EMPTY_VAR)
export PIPE := -pipe
endif
hbirr(a)svn.reactos.com wrote:
>Do always set the UserIosb of an irp in IoSecondStageCompletion.
>
>
>
>Updated files:
>trunk/reactos/ntoskrnl/io/irp.c
>
>
This is incorrect.
1) The IOSB should not always be set. Create a driver and fail an
operation that you send to yourself by an IRP. Make that IRP not
SYNCH_API, or better yet, make sure you don't have a File Object.
You will notice that the Status Block is not touched.
2) The IOSB is not checked if it exists, it should ALWAYS be there. IRPs
without a IOSB are invalid. To verify this, set the IOSB of your IRP to
0 and run Windows with a Debugger. You will see that it will break in
many places, because Windows has simply placed SEH to make sure that the
write is valid. So the correct thing to do is wrap the write in SEH,
which protects both against invalid pointers and zero ones, but that
still doesn't mean they are"valid" and should be checked that way.
Best regards,
Alex Ionescu
Hi:
I doubt this could be a bug. A lot of code would break with it. Maybe it does violates the short circuit in the small number of cases where that can be done. As in this case, it doesn't matters.
Regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Hartmut Birr
Sent: Tue 5/3/2005 2:43 PM
To: ReactOS Development List
Subject: [ros-dev] gcc problem or not
Hi,
I've looked on a map file from an optimized build. I found the following
code:
/*
* If the directory containing the file to open doesn't exist then
* fail immediately
*/
if (Status == STATUS_OBJECT_PATH_NOT_FOUND ||
12015: 83 c4 0c add $0xc,%esp
12018: 89 c3 mov %eax,%ebx
1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax
1201f: 0f 94 c2 sete %dl
12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax
12027: 0f 94 c0 sete %al
1202a: 09 d0 or %edx,%eax
1202c: a8 01 test $0x1,%al
1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9>
12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx
1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9>
Status == STATUS_INVALID_PARAMETER ||
Status == STATUS_DELETE_PENDING)
{
if (ParentFcb)
{
vfatReleaseFCB (DeviceExt, ParentFcb);
}
return(Status);
}
I was always the opinion that the examination of a test condition stops
if the result can not change again. A test condition like this:
if (pointer == NULL || pointer->member == 0)
should never access pointer->member if pointer is zero. Compared with
the code above, it is possible that gcc build the result from the right
side of the OR statement. This may hit a page fault. Is this a bug in gcc?
- Hartmut
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hi,
I've looked on a map file from an optimized build. I found the following
code:
/*
* If the directory containing the file to open doesn't exist then
* fail immediately
*/
if (Status == STATUS_OBJECT_PATH_NOT_FOUND ||
12015: 83 c4 0c add $0xc,%esp
12018: 89 c3 mov %eax,%ebx
1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax
1201f: 0f 94 c2 sete %dl
12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax
12027: 0f 94 c0 sete %al
1202a: 09 d0 or %edx,%eax
1202c: a8 01 test $0x1,%al
1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9>
12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx
1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9>
Status == STATUS_INVALID_PARAMETER ||
Status == STATUS_DELETE_PENDING)
{
if (ParentFcb)
{
vfatReleaseFCB (DeviceExt, ParentFcb);
}
return(Status);
}
I was always the opinion that the examination of a test condition stops
if the result can not change again. A test condition like this:
if (pointer == NULL || pointer->member == 0)
should never access pointer->member if pointer is zero. Compared with
the code above, it is possible that gcc build the result from the right
side of the OR statement. This may hit a page fault. Is this a bug in gcc?
- Hartmut
> From: ion(a)svn.reactos.com
>
> KD System Rewrite:
This utterly broke the GDB stub, to the point that I can't even use DbgPrint
anymore to try and figure out what's wrong. May I suggest you go and read
http://www.joelonsoftware.com/articles/fog0000000069.html first, revert this
patch (so I can get on with my work), and then, if you still feel this
overwhelming urge to rewrite, test all the functionality you're replacing
(you obviously didn't even consider a "/DEBUGPORT=GDB" and boot test
necessary) before recommiting.
If I sound a little bit pissed-off, that's because it's exactly how I feel.
This is not the first time I've been bitten by a rewrite. Back in January I
spent a lot of time improving symbol handling and profiling, only to see you
remove the profiling code a few weeks later, for a "new and improved"
rewrite. Only problem is, the "new and improved" profiling system doesn't
produce any output and is therefore useless. You said you would fix that in
a weeks time, but now, months later, still nothing. I'll be damned if I'm
going to let the same happen to the GDB stub, which I use on a daily basis.
We all break stuff sometimes (God knows I do) and I can live with that. I
can even live with rewrites when they're necessary for binary compatibility
(after all, that's what this project is all about) but I'm highly suspicious
of rewrites because of "well, uhmm, I think my way is cleaner".
Gé van Geldorp.
Hi,
we have somewhere a leakage which doesn't free unicode strings in kernel
mode. After a short time of compiling ros on ros, I see many blocks with
the tag USTR:
...
Tag 52545355 (USTR) Blocks 714270 Total Size 53114920 Average Size 74
...
TotalBlocks 758557 TotalSize 66314608 AverageSize 87
Freeblocks 21427 TotalFreeSize 323088 AverageFreeSize 15
- Hartmut
Hi,
--- Phreak(a)svn.reactos.com wrote:
> Renamed another makefile in the xmlbuildsystem branch that had the wrong case
I don't really care which case we use but if its going to be upper case Makefile can you add it
somewhere on the Wiki? Also maybe note about MixEd CaSeFileNames in SoUrce FIles.
Thanks
Steven
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi,
I'm searching for a position in our kernel mode code, which compares a
variable with STATUS_UNSUCCESSFUL. That does mean, there is somewhere a
'==' followed by 'STATUS_UNSUCCESSFUL' or 'STATUS_UNSUCCESSFUL' followed
by '=='.
- Hartmut
Hi all,
even if it is only an empty framework, I want to make you know yesterday
I committed the source code of an optional environment subsystem for
emulating VMS. Note it is far from complete and it has no ReactOS
specific code (which will be *required* to run), but it may be used as a
template.
Recently ReactOS, which is a free and open source reimplementation of
the core NT kernel+executive and driver model with multiple user mode OS
personalities, was added the effective ability to load other optional
subsystem, like POSIX (researched) or, say, VMS.
If somebody on the list is interested in this project, please, feel free
to contact me privately.
Emanuele Aliberti
ea(a)reactos.com
1st problem: when booting rev 14873 (DBG := 1, KDBG := 0) it crashes with:
DriverBase for \SystemRoot\system32\drivers\fs_rec.sys: 9cf7c000
(io/file.c:898) Status :0
(io/file.c:898) Status :0
(io/file.c:898) Status :0
DriverBase for \SystemRoot\system32\drivers\beep.sys: 9cf8b000
(io/file.c:898) Status :0
Assertion NewRefCount >= 0 failed at ob/object.c:1150
KeBugCheckWithTf at ke/catch.c:217
A problem has been detected and ReactOS has been shut down to prevent damage
to your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
KMODE_EXCEPTION_NOT_HANDLED
Technical information:
*** STOP: 0x0000001E (0x80000003,0x800057a4,0x8005d08b,0x8071c9ec)
*** ntoskrnl.exe - Address 0x800057a4 base at 0x80000000, DateStamp 0x0
Breakpoint Exception: 3(0)
Processor: 0 CS:EIP 8:800057a4 <ntoskrnl.exe: 57a4>
cr2 8ccfc000 cr3 27000 Proc: 8053fcf8 Pid: 4 <System> Thrd: 805407f0 Tid: 0
DS 10 ES 10 FS 30 GS 10
EAX: 00000036 EBX: 8004515d ECX: 00000000
EDX: 000003f8 EBP: 800e47a4 ESI: 800e4a84 ESP: 800e4730
EDI: 800e49f4 EFLAGS: 00200286 kESP 800e4730 kernel stack base 800e3000
Frames:
<ntoskrnl.exe: 72a9f>
<ntoskrnl.exe: 45f2a>
<ntoskrnl.exe: 456e1>
<vfatfs.sys: 2d00>
<vfatfs.sys: d1de>
<vfatfs.sys: d3ee>
<ntoskrnl.exe: 45158>
<ntoskrnl.exe: 40487>
<ntoskrnl.exe: 414dd>
<ntoskrnl.exe: 3602>
<7D83F045>
<ntoskrnl.exe: 3e6c0>
<ntoskrnl.exe: 3602>
<EC83FC45>
<ntoskrnl.exe: 3de8e>
<800A48CE>
<800A21D4>
<ntoskrnl.exe: 10004>
<800A07AA>
<ntoskrnl.exe: 104b>
2nd problem: the crash info is only written to the debug log and not shown
as a BSOD.
3rd problem: the stack trace only shows addresses, not source file/line as
it should for a DBG build
4th problem: booting with /DEBUGPORT=GDB results in a kernel stack fault
very early in the boot process.
Gé van Geldorp.
ion(a)svn.reactos.com wrote:
>Add hack for ROS's weird behavior. Will investigate but this lets you boot for now
>
>
>Updated files:
>trunk/reactos/ntoskrnl/io/irp.c
>
>
>
The problem is that a bunch of places in the code set the FileObject
Event as the UserEvent. This is incredibly wrong, because both are used
to signal completely different things and shouldn't be used like that.
I've changed them to local stack KEVENTS, but this still fails, because
you cannot dereference them. The check for !IRP_SYNCHRONOUS_API is meant
to ensure against this (Syncronous IRPs have KEVENTS, Async ones have
Executive Events, in short terms.) I've researched some more and this is
because of a bigger problem. The routines doing the hack all assumed
that the File Object is Synchronous and build a Sync FSD (with
IRP_SYNCH_API set), and then set a KEVENT UserEvent. They should
actually check if the File Object is Sync or Async, and in case of Async
they should use the Local Stack KEVENT (which won't be dereferenced
because of the check in IoCompleteRequest APC (2nd stage)), while in
case of async they shouldn't use any event at all and wait on the file
object instead of waiting on the local event. Also, in case of a sync
operation, we must eventually include some sort of locking/unlocking of
the file object for serialized access which is required. I will spend
some time tomorrow working with these issues so the hack can be removed
and proper kernel functionality to be restored, but I wanted to share
the background information.
Best regards,
Alex Ionescu
>>>
It's still not fully stable, card support is not great and it's only
configurable through regedit at the moment.
However it's all being worked on. Arty has done a fantastic job so far.
Ged.
<<<
Actually lately no regedit is needed, as long as reactos registry supports your card only the dhcp software is needed, then everything is working... ...and soon the controlpanel app will be ready and everyone with a compatible card will be able to configure easy.
The thing that we really need is support for driver installation.
But on the other hand when we releas a new version we could transfer it to a usual textfile and put it on the welcome screen.
/Jaix Bly
----Ursprungligt meddelande-----
From: Gedi gedi(a)ntlworld.com
Date: Sat, 30 Apr 2005 15:21:39 +0200
To: ReactOS Development List ros-dev(a)reactos.com
Subject: Re: [ros-dev] 0.2.7?
> Michael B. Trausch wrote:
>
> >Uh... Networking?
> >
> >I know at the very least *I* haven't seen ping working yet...
> >
> Networking has been up and running since before christmas now.
> Along with the Mozilla control, you can now browse the web with ROS'
> built in ibrowser, or use something like dillo.
> There are many other programs running too, email, IRC too name but a few.
>
> >Networking support at the very least should be a staple for most overly
> >popular cards before you think about trying to require a web page be
> >displayed for something. Instead, put a static page on the CD that gets
> >copied to the installed system.
> >
> >
> It's still not fully stable, card support is not great and it's only
> configurable through regedit at the moment.
> However it's all being worked on. Arty has done a fantastic job so far.
>
> Ged.
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
Good idea, but ones a month is to frequent, people will get tired of testing new versions that they can't see any difference between. I think it has to be focust releases where something actually can be tested or seen, a feature not just read about in a change-log, everyone doesn't read the changelog.
By the way, to be able to get people test the right thing when a new versin is released, we should have a welcome-screen packed with information about things changed since last release and so forth, this in a way that people can know how to test the new feature. This welcome screen could be a page in the WIKI so every developer easy can add what they want the testers to try out and how to do it. I know this opens for another problem, we need a browser to do that, can we add the mozilla-com plugin to the release? Or can we include another one?
----Ursprungligt meddelande-----
From: WaxDragon waxdragon(a)gmail.com
Date: Fri, 29 Apr 2005 19:13:29 +0200
To: ReactOS Development List ros-dev(a)reactos.com
Subject: [ros-dev] 0.2.7?
> I would like to see a 0.2.7 release soon. 0.3.0 is getting closer
> every day, but it's not there yet IMHO. On the other hand, we have
> had lots of big patches from Mr. Ionescu (and others), major changes,
> go in and appear to be stable since we have released 0.2.6. I would
> like to see us have another release in this lull, instead of having a
> release right after committing a pile of patches *right before* the
> release like we did with 0.2.6.
>
> I know it's been less than a month since 0.2.6, but my the time we
> branch and do a couple RC's, it will have been over a month.
>
> I just have this feeling that we miss some regressions from release to
> release, since alot of us just use HEAD on a regular basis?
>
> Just my $0.2US
> WD
> --
> "<tinus_> and also win32k should be fixed up a bit"
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
I have a simple request for when ReactOS wants to add updates to system
software when Service Packs and Updates become available.
I think that a ReactOS computer should utilize a small system service that
indexes file version numbers, indexes them on importance, size, type, and
other information. This can be done on a flatfile, XML, or a SQL Database
connection. Then the server sends reponses back to the computer offering
service packs, files, device drivers, etc.
I think that kind of system will allow easy updates to ReactOs on users
computers while not having to reinstall or reformat.
Something like up2date, or mac os x¹s update program. The system can maybe
support rollback of files.
Just an idea.
Yesterday reactos.com crashed. Unfortunately, I was unable to go onsite to
fix the problem yesterday. This morning, I rebooted the box and everything
seems to be up and running again.
It seems some mail sent to @reactos.com yesterday may have been dropped.
Ge van Geldorp.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Christof Petig wrote:
|
| This limitation really hurts if you do not plan to use ROS exclusively
| on that computer (e.g. if you do not want to throw XP away completely or
| you already use a first primary partition for linux).
|
ROS and XP can share the same partition. It just cannot be NTFS. You
can always move partitions around.
And yes, while the limitation "hurts," that's a workaround that you can
use. Short of editing the source code, I'm not sure if there's much
that can be done. I'll cc: this to the dev list and ask if the
limitation still is there, but I personally don't see anything about it
having changed. Consider that ROS is still in "early" stages of
use/release. 0.3 hasn't even been released yet. I am sure that when
the partition/fs code is better able to deal with multiple partition
setups, it will all work as it would be anticipated it would.
- Mike
- --
Michael B. Trausch <fd0man(a)gmail.com>
Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com
Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647
===================================================================
Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCbiTLPXInbkqM7nwRAwl+AJ9U7aJ/HjCf72KuEkj4SjcM0wrpXgCfb6bs
k9UbhobagYdusxcub9csK7U=
=w/H8
-----END PGP SIGNATURE-----
Hi,
If you need it here it is. Only explorer.exe does not build. The rest will compile if you shutup
-Werror. For the C++ code that I have compared vs 3.4.1 its almost 2x faster.
Thanks
Steven
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Vote results (Which kernel you prefer to see as base of osFree kernel?):
What
Percentage
Votes
L4
30.6 %
609
Linux
13.4 %
267
Mach
7.2 %
144
ReactOS
43.9 %
874
Other
4.4 %
87
This poll is taken from http://www.osfree.org/index.php
Hi!
I programmed the ReactOS Package Manager - Online Website (started
yesterday). It provide the online database (xml database) for the ReactOS
Package Manager (exe) (svn: /trunk/rosapps/packmgr).
Some important main function of the page already work. The page (written in
php with mysql database) provide the database files (static xml files) for
the client (packmgr.exe).
So the Package Manager only download some static xml files (spare server
resources).
Url: http://frik85.fr.funpic.de/packmgr/ (for test purposes)
Test the package manager (in Win32) with the new online database:
* Compile the packmgr files (gui-app + dll)
* change the server in option.xml to:
<options>
<source>http://frik85.fr.funpic.de/packmgr/db/</source>
</options>
* start the gui application (packmgr.exe)
Wiki-Page: http://reactos.com/wiki/index.php/ReactOS_Package_Manager
Klemens Friedl
--
+++ GMX - Die erste Adresse f�r Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail
Hi,
I've found some other problems. For the serial debug, the default
baudrate is set to 19200 baud and the baudrate option has no effect. Two
debug port options like "/DEBUGPORT=BOCHS /DEBUGPORT=COM2" switches my
pc off. The on/off switch has no effect after this. I must remove/insert
the power plug to boot the pc again. I use this option for the bootcd.
The previous debug implementation has enabled the bochs and serial debug
at boot phase 0 and all other debug variants at boot phase 1. Currently
KdInitSystem(0, ..) is called twice. The first call is in _main and the
second in ExpInitializeExecutive.
- Hartmut
Hi,
your changes breaks compiling with DBG := 1 and KDBG := 0.
- Hartmut
ion(a)svn.reactos.com wrote:
>KD System Rewrite:
>
> - Totally dynamic based on the principle of Native Providers built-in the Kernel (like Screen,
> FileLog and Serial) and a pluggable Wrapper which is optionally compiled (Bochs, GDB)
> - Nothing changed in KDBG, except for that its settings (KDSERIAL/KDNOECHO) are now stored in
> KdbDebugState instead.
> - Wrappers are currently built uncondtionally. With rbuild, I'll make them easily removable.
> - Debug Log code simplified greatly, sped up and now supports printing even the first boot messages,
> which wasn't supported before.
> - Removed most of KDBG compile-time settings, ones which are needed are in include/dbg as macros now.
> - Left in some kdbg init code and break code, but it could be made to be used as a 'wrapper' for those
> functions. I will do it later.
> - Made a hack for KdpEnterDebuggerException..it seems to be called differently and at different times
> for GDB vs KDBG and I couldn't unite them.
> - KdpServiceDispatcher now does both the documented and ros-internal debug functions and will eventually
> be called through INT2D from keyboard.sys instead of as an API.
>
>All in all, this patch makes KD separated from KDBG and creates a pluggable architecture for creating future wrappers that don't require changing tons of code in the future. It improves the debug
>log by printing even the earliest debug messages to it and it removes many of the manual ifdef(KDBG) but making them automatic though a single macro file. It makes extra debugging functionality optional and it
>allows removal of a private API from our exports.
>
>
>Added files:
>trunk/reactos/ntoskrnl/include/internal/kdbochs.h
>trunk/reactos/ntoskrnl/include/internal/kdgdb.h
>trunk/reactos/ntoskrnl/kd/kdinit.c
>trunk/reactos/ntoskrnl/kd/kdio.c
>trunk/reactos/ntoskrnl/kd/kdmain.c
>trunk/reactos/ntoskrnl/kd/wrappers/
>trunk/reactos/ntoskrnl/kd/wrappers/bochs.c
>trunk/reactos/ntoskrnl/kd/wrappers/gdbstub.c
>
>Updated files:
>trunk/reactos/drivers/input/keyboard/keyboard.c
>trunk/reactos/include/ddk/kefuncs.h
>trunk/reactos/ntoskrnl/Makefile
>trunk/reactos/ntoskrnl/ex/init.c
>trunk/reactos/ntoskrnl/include/internal/dbg.h
>trunk/reactos/ntoskrnl/include/internal/kd.h
>trunk/reactos/ntoskrnl/include/internal/kdb.h
>trunk/reactos/ntoskrnl/include/internal/ke.h
>trunk/reactos/ntoskrnl/include/internal/module.h
>trunk/reactos/ntoskrnl/include/ntoskrnl.h
>trunk/reactos/ntoskrnl/io/iomgr.c
>trunk/reactos/ntoskrnl/io/pnpreport.c
>trunk/reactos/ntoskrnl/kd/service.c
>trunk/reactos/ntoskrnl/kdbg/kdb.c
>trunk/reactos/ntoskrnl/kdbg/kdb_cli.c
>trunk/reactos/ntoskrnl/kdbg/kdb_serial.c
>trunk/reactos/ntoskrnl/kdbg/kdb_symbols.c
>trunk/reactos/ntoskrnl/ke/bug.c
>trunk/reactos/ntoskrnl/ke/catch.c
>trunk/reactos/ntoskrnl/ke/i386/exp.c
>trunk/reactos/ntoskrnl/ke/i386/irq.c
>trunk/reactos/ntoskrnl/ke/i386/syscall.S
>trunk/reactos/ntoskrnl/ldr/loader.c
>trunk/reactos/ntoskrnl/mm/RPoolMgr.h
>trunk/reactos/ntoskrnl/mm/marea.c
>trunk/reactos/ntoskrnl/ntoskrnl.def
>
>Deleted files:
>trunk/reactos/ntoskrnl/kd/dlog.c
>trunk/reactos/ntoskrnl/kd/gdbstub.c
>trunk/reactos/ntoskrnl/kd/kdebug.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
> From: ion(a)svn.reactos.com
>
> Add GDB = 1 to makefile to compile-in the GDB Wrapper. These
> options will be better manged with rbuild
Any reason the inclusion of the GDB stub can't be keyed on the existing
"DBG" var? I feel (pretty strongly) we should minimize the number of
compile-time configs.
Gé van Geldorp.
> -----Original Message-----
> From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of
> ion(a)svn.reactos.com
> Sent: 25. april 2005 17:20
> To: ros-svn(a)reactos.com
> Subject: [ros-svn] [ion] 14801: Add GDB = 1 to makefile to compile-in theGDB Wrapper. These options
> will be better manged with rbuild
>
> Add GDB = 1 to makefile to compile-in the GDB Wrapper. These options will be better manged with
> rbuild
>
>
> Updated files:
> trunk/reactos/config
Experience has told us that with compile-time options come more compilation errors (and we have enough of those). Please compile it
in always and make it a run-time option instead to avoid this. The extra bytes are well spent.
Casper
rbuild has one bug ( that we're aware of ) blocking it from being ready
to go live.
Basically, both bootcd and livecd are halting with a
"inaccessible_boot_device" after blue.sys.
Would anybody be willing to look at it and help us figure out what we're
doing wrong when generating the ISOs?
Also, being this close, would everybody who cares please check out the
rbuild branch for feedback before we go live?
Here's the branch url: svn://svn.reactos.com/branches/xmlbuildsystem/reactos
Thanks
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I hit the start menue entry to kill explorer.
I'm running this on QEMU 0.6.1. -user-net is enabled.
Then this problem appeared. Just look at the screenshot.
I just want to report that problem.
Greetings,
Jan Schiefer!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCa4SYzC00UKXFdVcRAi8vAKCwVQKvLbisZ2P9qz+TFv5qzf+R0QCfbmwa
2+fVvDWgGnGWGeQ7u/TYkFA=
=ow9s
-----END PGP SIGNATURE-----
Hi Hartmut & Mm Experts,
It seems that on ROS, every process has its own Page Table for the
Kernel Area/System Table. This needs to be updated with MmUpdatePageDir
all the time, and creates a bunch of annoyances in the Context Switching
code too (for example, I can't check the trap frame for VM_MASK because
at that time the Page Directory hasn't been changed yet. I could change
it before but that would screw up the optimizations. Philip Susi and I
have researched this and arrived to the common conclusion that every new
Process's Page Table should share the same System Page Table. I'm not an
expert so maybe I'm not explaining it properly, but the System Page
Table shouldn't have to be "inserted/mapped" into every Process's Page
Table, it should already be there, shared amongst all processes.
I hope that made sense...if not, maybe Philip can fix up my explenation.
Is it possible for any of the Mm guys to implement this properly?
Thanks a lot..
Best regards,
Alex Ionescu
Trying to compile ros trunk with config set to DBG=1 and KDBG=0,
I get the following errors into ntoskrnl.
Can someone help ?
ke/i386/exp.o: In function `KeRosPrintAddress':
/mnt/hdb5/reactos/reactos/ntoskrnl/ke/i386/exp.c:113: undefined reference to `_KdbSymPrintAddress'
ex/dbgctrl.o: In function `NtSystemDebugControl':
/mnt/hdb5/reactos/reactos/ntoskrnl/ex/dbgctrl.c:38: undefined reference to
`_KdbSymLoadUserModuleSymbols'
io/driver.o: In function `IoDestroyDriverList':
/mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:(.text+0x568): undefined reference to
`_KdbSymProcessBootSymbols'
io/driver.o: In function `IopInitializeBootDrivers':
/mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:1262: undefined reference to
`_KdbSymProcessBootSymbols'
io/driver.o: In function `IopInitializeBuiltinDriver':
/mnt/hdb5/reactos/reactos/ntoskrnl/io/driver.c:(init+0x67c): undefined reference to
`_KdbSymProcessBootSymbols'
ldr/loader.o: In function `LdrUnloadModule':
/mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:404: undefined reference to
`_KdbSymUnloadDriverSymbols'
ldr/loader.o: In function `LdrLoadModule':
/mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:387: undefined reference to
`_KdbSymLoadDriverSymbols'
ldr/loader.o: In function `LdrUnloadModule':
/mnt/hdb5/reactos/reactos/ntoskrnl/ldr/loader.c:422: undefined reference to `_KdbSymInit'
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
After these changes, both the livecd and bootcd hang qemu and cause
vmware to stack fault and reboot.
WD
--
"<tinus_> and also win32k should be fixed up a bit"
Hi,
our current thread and process structures have two thread lists, one in
KPROCESS/KTHREAD and another in EPROCESS/ETHREAD. Do we need both lists?
- Hartmut
hpoussin(a)svn.reactos.com wrote:
>Add Green driver, that emulates a VT100 compatible server.
>Input won't work as long as we don't have a kdbclass driver.
>
>
>
>
Why don't you commit tinus' I8042PRT?
Best regards,
Alex Ionescu
Art,
The freeldr changes I just checked in more or less formalize the concepts of
a boot volume/partition (containing freeldr.sys and freeldr.ini) and a
system volume/partition (containing \ReactOS). Most of the time, the boot
volume and system volume will be the same, but it's not required. The main
freeldr code no longer knows anything about partitions, this is handled in
the architecture-dependent functions now. The main code is given an opaque
drive number and the sector number at which a partition/slice/volume starts.
There are a number of new Mach functions:
BOOL
MachDiskGetBootVolume(PULONG DriveNumber, PULONGLONG StartSector, PULONGLONG
SectorCount, int *FsType)
which should return the boot DriveNumber (the main freeldr code just hands
it back to MachDiskReadLogicalSectors when needed), the StartSector of the
boot partition/slice/whatever, the SectorCount of the boot
partition/slice/whatever and the FsType (FS_FAT, FS_EXT2 etc.). The i386
MachDiskGetBootVolume() uses the boot drive and boot partition passed in by
the BIOS/boot sector to set the values, but the ppc implementation is
ofcourse free to handle it in its own way.
BOOL
MachDiskGetSystemVolume(char *SystemPath,
char *RemainingPath,
PULONG Device,
PULONG DriveNumber,
PULONGLONG StartSector,
PULONGLONG SectorCount,
int *FsType)
This routine takes a SystemPath, which for i386 is something like
multi(0)disk(0)rdisk(0)partition(1)\ReactOS and finds the DriveNumber,
StartSector, SectorCount and FsType from that. If RemainingPath is non-NULL,
in this example it will return \ReactOS in it. Device can be NULL, if it's
not the value appropriate for LoaderBlock.BootDevice will be returned there.
The format of the SystemPath passed in is architecture-dependent. It's taken
from freeldr.ini and passed on to MachDiskGetSystemVolume() by the main
freeldr code without any attempt to interpret it.
BOOL
MachDiskGetBootPath(char *BootPath, unsigned Size)
This constructs a system path for the boot volume. The i386 routine does
this by referencing its internal i386BootDrive and i386BootPartition
variables.
VOID
MachDiskGetBootDevice(PULONG BootDevice)
Returns a suitable value for LoaderBlock.BootDevice for the boot volume.
BOOL
MachDiskBootingFromFloppy()
Returns TRUE when booting from a low-capacity device.
Gé van Geldorp.
ion(a)svn.reactos.com wrote:
>Thread Creation and Context Switching re-write, plus Idle/First Thread minimization attempt. Full changelog on ML, too large to post here
>
>
Main Differences in new Task Swithcer:
- All written in Intel Syntax
- Single file and function handles both cases of System and User thread
switching and contexts.
- Starting Frame creation during Thread Context Creation is now
structure-based instead of a stack array. Cleaner
to read and more explicative.
- ExceptionList is properly set to -1 when needed. This should make PSEH
2 work.
- Context switch routine now has ALL registers available to it,
including EBP.
- Context switch routine uses access to KPCR through a register,
improving speed.
- KPCR Stack Data properly updated during context switch.
- KTSS CR3 properly updated during context switch.
- LDT, CR3 and IOPM are only updated if the new thread's process is
different, increasing speed for the simple path.
- The LDT and TEB Selectors are written directly in the GDT, bypassing a
complicated STDCALL routine which messed up
registers and was slow.
- Kthread.ContextSwitches is properly incremented now.
- Kthread.State is properly set to Running now.
The three goals were Speed, Clarity, Completeness.
Other Differences:
- Threads used to start either in PsBeginThread or
PsBeginThreadWithContext. PsBeginThread would lower to passive and call
the start routine with the start context, then terminate.
PsBeginThreadWithContext also lowered irql, but then restored debug
registers and used KiServiceExit to go to user-mode. A new function now
exists called KiThreadStartup, based on NT's implementation (see Inside
Windows 2000). It lowers IRQL to APC_LEVEL and then calls the System
Routine, which is on the stack with the two parameters (StartRoutine and
STartcontext). This System Routine ressembles
PsBeginThread/PsBeginThreadWithContext. Depending on how the thread was
created, it can either by PspSystemThreadStartup, which lowers IRQL to
passive and then calls the StartRoutine. Or, it can be
PspUserThreadStartup, which queues the User-Mode APC and inserts it,
then lowers IRQL to passive and notifies the Debugger. Notice that the
APC is now queued here, much later then before. After that, we return to
KiThreadStartup, which will bugcheck if the system thread returned (it
shouldn't), or will use KiServiceExit2, which does the same as the old
ros, which is to restore the debug registers. IT then immediately does
an IRET after cleaning the trap frame. Calling KiServiceExit is not
correct because it might end up using SYSEXIT when clearly we weren't
SYSENTERED.
- Idle thread, first thread, first process and idle process are concepts
which ROS gets really wrong. I have a patch which fixes these issues,
but it is still heavily under testing. Until then, this patch also
includes some changes which make the Idle/First Thread much less heavy,
and are simple blocks of memory with the minimum amount of data possible
to have a working system. They are not objects anymore, nor should they
be. This isn't the final implementation but ressembles it and lays the
minimal groundwork.
- I will make a shorter patch-fix which will make
Ki386InitializeThreadWithContext use the KeContextToTrapFrame function
and complete it as well, in order to use only the fields which were
specified by the caller.
Best regards,
Alex Ionescu
fireball(a)svn.reactos.com wrote:
> Added xbox video driver information (by GvG), I hope it doesn't interfere anyone, and there will be no need to patch registry everytime to boot under xbox.
>
>
> Updated files:
> trunk/reactos/bootdata/hivesys.inf
>
Is it possible to add also the nic realtek8139 and nvidia display driver
informations as well for the same need ?
Regards
Gerard
Hi:
I doubt normal Windows users will be downloading sources of anything ever. BTW is a lot more dificult to set the build environment than to decompress the sources using 7zip. Beleiveme is a real pain to download ROS if you have a dialup connection. Why waste our time when we don't need to. Again if still you consider that a zip distribution should still be available for download why not distribute both zip and 7zip. Is that much space? Or it takes to much time to pack? I would answer no to both questions.
Regards
Waldo
-----Original Message-----
From: ros-dev-bounces(a)reactos.com on behalf of Andrew Flynn
Sent: Thu 4/14/2005 4:28 AM
To: ReactOS Development List
Subject: Re: [ros-dev] 7-zip - holy smokes!
I agree with Michael B.
7Zip is superior to ZIP. You have to remember who will be downloading
the source, compressed files. Is it going to be standard windows users
that use winzip and nothing else?
When it comes to mass distribution of images, the iso format seems like
a sensible choice, where the setup programs can utilise whatever
compression they like. PKZip may be the most popular, but that does not
mean that ReactOS files have to use it.
Michael B. Trausch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: RIPEMD160
>
>Thomas Weidenmueller wrote:
>
>
>>I don't think it's a good choice for our public downloads, the avarage
>>user most likely will not know this format. zip still is THE standard.
>>
>>
>>
>
>True, it is. However, end-users will follow whatever trends are set for
>them. ZIP got to be big and well-known because of PKZip, honestly.
>
>If 7-Zip is that much better, then I'd say we go for it and put in
>something like red text above the link to the downloads page that we use
>7-Zip.
>
>Or, we could give users their option and offer both. Those concerned
>about bandwidth would use the 7-Zip version, and those who don't care
>can go with the other one.
>
>As far as users and .EXE files - End Users download EXE files all of the
>time. They don't know any better. They see the box in MSIE and go,
>"Yeah, whatever, it's my computer and I wanna download it," click it
>away and move on. *shrugs*
>
>That's why I make money outside of my job, cleaning up after people's
>idiotic mistakes, but that's another story altogether. If we offer them
>a self-extracting version and a 7-Zip'd version, that'd be even better
>in terms of download time/bandwidth.
>
>Not to mention, if 7-Zip can be distributed with ReactOS, it's a good
>way to get it out there. Since it's under LGPL, it'd be something that
>could even be built into ReactOS in the same way as .ZIP format support
>is built into more recent versions of Windows (and hopefully, just as
>easy to disable, because I hate that feature, but plenty of people
>absolutely love it).
>
>Not only all of that, but since it's a superior compression scheme, it'd
>be logical to support it and help further it's distribution so that
>people would use it. People don't just sit down very frequently and go,
>"Hrm. I think I am going to search out a new way to compress my files,"
>because they figure that compression is compression is compression, and
>that's all there is to it.
>
>All in all, I think it'd be wise, especially over the long-term, to use
>and support 7-Zip.
>
> - Mike
>
>- --
>Michael B. Trausch <fd0man(a)gmail.com>
>Website: http://fd0man.chadeux.net/ Jabber: mtrausch(a)jabber.com
>Phone: +1-(678)-522-7934 FAX (US Only): 1-866-806-4647
>===================================================================
>Do you have PGP or GPG? Key at pgp.mit.edu, Please Encrypt E-Mail!
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.1 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFCXcHQPXInbkqM7nwRA4D1AJ93vO8bTantG9QSWgtejVN0CotNiQCfe1rM
>z6njCB0ucQYWNIAoofS9bD8=
>=d5Zf
>-----END PGP SIGNATURE-----
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-dev
>
>
>
>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hi all
I remember someone removed the 'User Site' from the ReactOS banner on
our current site. Can that someone please send me the image, it seems
people would like to see it on the new site design.
Thanks
Jason
Hello,
Currently I'm experiencing two problems.
Is there any plan to fix them?
1. ros-diffs list no longer delivers HTML mails. (since revision 14639)
2. Accessing to http://svn.reactos.com/viewcvs/ now requires an authentication.
(I don't know exact date of occurrence)
Thanks,
--
d_layer
Hi,
Need to check this one too.
make[1]: Entering directory `/home/ros/rosapps/sysutils/ctm'
ctm: [CC] ctm.c
ctm.c: In function `PerfDataRefresh':
ctm.c:356: error: `PSYSTEM_PROCESSES' undeclared (first use in this function)
ctm.c:356: error: (Each undeclared identifier is reported only once
ctm.c:356: error: for each function it appears in.)
ctm.c:356: error: syntax error before "pSPI"
ctm.c:361: error: `PSYSTEM_PROCESSORTIME_INFO' undeclared (first use in this function)
ctm.c:361: error: syntax error before "SysProcessorTimeInfo"
ctm.c:377: error: `SysProcessorTimeInfo' undeclared (first use in this function)
ctm.c:377: error: syntax error before "malloc"
ctm.c:378: error: `SYSTEM_PROCESSORTIME_INFO' undeclared (first use in this function)
ctm.c:382: error: syntax error before ')' token
ctm.c:419: error: `pSPI' undeclared (first use in this function)
ctm.c:419: error: syntax error before "pBuffer"
ctm.c:431: error: syntax error before "pBuffer"
make[1]: *** [ctm.o] Error 1
make[1]: Leaving directory `/home/ros/rosapps/sysutils/ctm'
James
Thanks Martin!
On 4/17/05, J.S. Martin <josmar52789(a)gmail.com> wrote:
> I think you guys are doing a great job with ReactOS. I tried it out
> about a year ago and I thought it was OK, not useful to my needs, but
> a good effort. Then I tried it out yesterday and I was absolutely
> amazed! If you guys keep trying and keep making progress, you will
> certainly make this a great OS and I will definitely be willing to use
> it all the time. Keep up the great work!
> --
> J.S. Martin
>
WARNING: This e-mail has been altered by MIMEDefang. Following this
paragraph are indications of the actual changes made. For more
information about your site's MIMEDefang policy, contact
MIMEDefang Administrator <postmaster(a)deos.tudelft.nl>. For more information about MIMEDefang, see:
http://www.roaringpenguin.com/mimedefang/enduser.php3
An attachment named listdlls.exe was removed from this document as it
constituted a security hazard. If you require this document, please contact
the sender and arrange an alternate means of receiving it.
Hi,
Here is list dlls utility,
James
Hello everybody,
I've uploaded a "patch" to bugzilla that adds support for Swiss German
keyboards (kbdsg.dll) to ReactOS.
http://www.reactos.com/bugzilla/show_bug.cgi?id=509
(The zip-file I uploaded contains the content of .../lib/kbdsg)
I've tested it on qemu and on real hardware and as far as I can tell it
works great. It would be great if it were included into the official
ReactOS sources. If you need any further information (or files) please let
me know.
kind regards
Roman Hoegg
roman.hoegg(a)unisg.ch
romanh(a)unisg.ch
P.S. I'm sorry if you have received this email twice. I tried to send this
information to the mailinglist yesterday but it didn't seem to get
through.
------------------------------------------
Roman Högg
Research Assistant
=mcm institute
for Media and Communications Management
University of St. Gallen, Switzerland
Blumenbergplatz 9, 9000 St. Gallen
Phone +41 (0)71 224 34 39
Mobile +41 (0)79 418 59 13
e-mail roman.hoegg(a)unisg.ch
http://www.mcm.unisg.ch
Hi,
I am experiencing problems building current source as follows
gdi32: [LD] gdi32.nostrip.dll
objects/brush.o(.text+0x52): In function `CreateDIBPatternBrush':
I:/reactos/lib/gdi32/objects/brush.c:41: undefined reference to
`NtGdiCreateDIBBrush@16'
objects/brush.o(.text+0xc7): In function `CreateDIBPatternBrushPt':
I:/reactos/lib/gdi32/objects/brush.c:71: undefined reference to
`NtGdiCreateDIBBrush@16'
collect2: ld returned 1 exit status
make[1]: *** [gdi32.nostrip.dll] Error 1
make: *** [gdi32] Error 2
I have made sure I am fully current with the source and have tried a full
"clean" but to no avail.
Can anyone throw some light onto this problem.
Mike Lerwill
Hi,
I guess that the implementation of strtoull is slightly wrong.
The current function prototype is:
unsigned long
strtoull(const char *nptr, char **endptr, int base)
But (IMHO) it should be:
unsigned long long
strtoull(const char *nptr, char **endptr, int base)
A patch is attached. This patch tries to determine the macro that
defines the maximum value for an unsigned long long and the
corresponding type. It tests for the existance of several macros and
optionally falls back to an unsigned long (you might want to remove this
"feature" - don't know if it's useful). The header file
<internal/file.h> is added to make it compilable without warning. I
changed both strtoull.c files but it seems that neither of them is
compiled/used, therefore I added strtoull.o to the lib/crt/makefile.
The existance of the sources below lib/crtdll/ is very confusing because
these sources arent't compiled at all. What's the cause to keep them in
the repository?
BTW: Where's the definition of strtoll? Is it required? Or was my work
useless at all?
Regards,
Mark
Index: lib/crt/stdlib/strtoull.c
===================================================================
--- lib/crt/stdlib/strtoull.c (revision 14631)
+++ lib/crt/stdlib/strtoull.c (working copy)
@@ -4,21 +4,49 @@
#include <ctype.h>
#include <errno.h>
#include <stdlib.h>
-//#include <msvcrt/unconst.h>
+/* #include <msvcrt/unconst.h> */
+/* required to get prototype for __set_errno() */
+#include <internal/file.h>
+
+#if defined(LONG_LONG_MAX)
+/* GCC-style constant */
+#define ROS_LLONG_MAX LONG_LONG_MAX
+#define ROS_ULLONG_MAX ULONG_LONG_MAX
+typedef long long ros_ll;
+typedef unsigned long long ros_ull;
+#elif defined(_I64_MAX)
+/* MSVC-style constant */
+#define ROS_LLONG_MAX _I64_MAX
+#define ROS_ULLONG_MAX _UI64_MAX
+typedef __int64 ros_ll;
+typedef unsigned __int64 ros_ull;
+#elif defined(LLONG_MAX)
+/* C9x-style constant */
+#define ROS_LLONG_MAX LLONG_MAX
+#define ROS_ULLONG_MAX ULLONG_MAX
+#include <stdint.h>
+typedef int64_t ros_ll;
+typedef uint64_t ros_ull;
+#else
+#define ROS_LLONG_MAX LONG_MAX
+#define ROS_ULLONG_MAX ULONG_MAX
+typedef long ros_ll;
+typedef unsigned long ros_ull;
+#endif
+
/*
* Convert a string to an unsigned long integer.
*
* Ignores `locale' stuff. Assumes that the upper and lower case
* alphabets and digits are each contiguous.
*/
-unsigned long
+ros_ull
strtoull(const char *nptr, char **endptr, int base)
{
const char *s = nptr;
- unsigned long acc;
+ ros_ull acc, cutoff;
int c;
- unsigned long cutoff;
int neg = 0, any, cutlim;
/*
@@ -43,8 +71,8 @@
}
if (base == 0)
base = c == '0' ? 8 : 10;
- cutoff = (unsigned long)ULONG_MAX / base;
- cutlim = (unsigned long)ULONG_MAX % base;
+ cutoff = (ros_ull)ROS_ULLONG_MAX / base;
+ cutlim = (int) ((ros_ull)ROS_ULLONG_MAX % base);
for (acc = 0, any = 0;; c = *s++)
{
if (isdigit(c))
@@ -65,7 +93,7 @@
}
if (any < 0)
{
- acc = ULONG_MAX;
+ acc = ROS_ULLONG_MAX;
__set_errno ( ERANGE );
}
else if (neg)
Index: lib/crt/makefile
===================================================================
--- lib/crt/makefile (revision 14631)
+++ lib/crt/makefile (working copy)
@@ -369,6 +369,7 @@
stdlib/strtod.o \
stdlib/strtol.o \
stdlib/strtoul.o \
+ stdlib/strtoull.o \
stdlib/swab.o \
stdlib/wcstod.o \
stdlib/wcstol.o \
Index: lib/crtdll/stdlib/strtoull.c
===================================================================
--- lib/crtdll/stdlib/strtoull.c (revision 14631)
+++ lib/crtdll/stdlib/strtoull.c (working copy)
@@ -4,21 +4,46 @@
#include <msvcrt/ctype.h>
#include <msvcrt/errno.h>
#include <msvcrt/stdlib.h>
-//#include <msvcrt/unconst.h>
+/* #include <msvcrt/unconst.h> */
+#if defined(LONG_LONG_MAX)
+/* GCC-style constant */
+#define ROS_LLONG_MAX LONG_LONG_MAX
+#define ROS_ULLONG_MAX ULONG_LONG_MAX
+typedef long long ros_ll;
+typedef unsigned long long ros_ull;
+#elif defined(_I64_MAX)
+/* MSVC-style constant */
+#define ROS_LLONG_MAX _I64_MAX
+#define ROS_ULLONG_MAX _UI64_MAX
+typedef __int64 ros_ll;
+typedef unsigned __int64 ros_ull;
+#elif defined(LLONG_MAX)
+/* C9x-style constant */
+#define ROS_LLONG_MAX LLONG_MAX
+#define ROS_ULLONG_MAX ULLONG_MAX
+#include <stdint.h>
+typedef int64_t ros_ll;
+typedef uint64_t ros_ull;
+#else
+#define ROS_LLONG_MAX LONG_MAX
+#define ROS_ULLONG_MAX ULONG_MAX
+typedef long ros_ll;
+typedef unsigned long ros_ull;
+#endif
+
/*
* Convert a string to an unsigned long integer.
*
* Ignores `locale' stuff. Assumes that the upper and lower case
* alphabets and digits are each contiguous.
*/
-unsigned long
+ros_ull
strtoull(const char *nptr, char **endptr, int base)
{
const char *s = nptr;
- unsigned long acc;
+ ros_ull acc, cutoff;
int c;
- unsigned long cutoff;
int neg = 0, any, cutlim;
/*
@@ -43,8 +68,8 @@
}
if (base == 0)
base = c == '0' ? 8 : 10;
- cutoff = (unsigned long)ULONG_MAX / base;
- cutlim = (unsigned long)ULONG_MAX % base;
+ cutoff = (ros_ull)ROS_ULLONG_MAX / base;
+ cutlim = (int) ((ros_ull)ROS_ULLONG_MAX % base);
for (acc = 0, any = 0;; c = *s++)
{
if (isdigit(c))
@@ -65,7 +90,7 @@
}
if (any < 0)
{
- acc = ULONG_MAX;
+ acc = ROS_ULLONG_MAX;
errno = ERANGE;
}
else if (neg)