Hi Gunnar:
Great! less duplicated code == better code
I had planning to report this about msvcrt/crtdll the first chance I could get to read my e-mail, but now that you talked then there's no better chance than this I think. I was playing with msvcrt dll a couple of days ago because I was trying to test some apps against it and to maybe find some of the multithreading issues it contains. Well I dropped it because I really had no time but one thing I noticed is that there are some entries in the .def file something like this strlen=ntdll.strlen only strings routines if I remember well. Now after I got the binary file (.dll) I was inspecting it with LordPE, a tool to sniff every detail of PE's and saw that actually those routines are not imported by crtdll (maybe because of the strings.a statically linked) also I saw that msvcrt.dll is importing functions from itself funny that is something I never saw before (Is ROS parsing the exports table before the imports one? Just curious). But worst there are 2 references to msvcrt with different functions that the -O flag when passed to the linker can't fix. I have seen this before in some applications compiled with mingw (freecraft for example. Could be this an unnoticed bug in mingw's linker? If It is, it doesn't harm but it sucks to not have it the better way you can if it is easy to do it). btw I was also looking for string routines exported by ntdll in order to squeeze a bit more both libraries and noticed in XP's ntdll some functions that at the beginning I thought were mistyped (It would not be the first time) but when I took a look at msdn Tada! WindowsCE functions, nothing about XP/2k... but there they ARE. Please do not forget to fix those problems with exports if you can, or anyone with a chance, those libraries stink a lot. I still don't understand every detail on how the whole thing works: build system, linker... so this is a "I don't know how to fix", at least for now.
Best Regards
Waldo Alvarez
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Gunnar Dalsnes
Sent: Wed 1/26/2005 8:19 PM
To: ReactOS Development List
Subject: [ros-dev] msvcrt/crtdll "merge"
Hi,
I'm currently "merging" msvcrt and crtdll (again). I'll move msvcrt into
a library lib\crt and have msvcrt and crtdll link against it. Only
dllmain.c will be left in msvcrt/crtdll. Most of (99.9%) crtdll will be
dropped. It all seems to work nicely. One problem thou: I ran into some
header problems, where i relied on some stuff in include\msvcrt\string.h
but no matter what, mingw\include\string.h were included instead (and
they both defined _STRING_H_). After looking at the headers in
inlcude\msvcrt they all seem to be ripped from mingw. Does anyone know
why they were put in include\msvcrt when mingw has headers for all of
this stuff? Can i just remove them (include\msvcrt)?
I looked at many depends files and saw most files depend on many mingw
headers. Is this correct? Should we depend on mingw headers at all?
Gunnar
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Dear ReactOS enthusiasts and friends,
We are currently in dire need of motivated people to help us build the
future OS of the masses. While our developers are busily creating new
code and fixing bugs, there remain dozens, if not more, of things to
take care of in our tree and in our code. I would like to extend an open
invitation to anyone interested on becoming a JANITOR (Just A Newbie
Intensively Training On ReactOS).
As a JANITOR, you will join a team of people, which, just like you, want
to see ReactOS succeed and have some spare time to help. You do NOT need
any coding experience! Most of the time, only simple word processing
skills are needed. Janitorial jobs will include cleaning up comment
headers, standardizing the debug system, alphabetizing code and
organizing files, compiling a list of fixmes, checking for spelling
mistakes, etc. These jobs will be custom tailored to your abilities, and
there will be no time limits (but you must commit to doing the job).
Also, JANITORs will have access to an online collaboration site where
the current top-priority jobs are presented, and where they can commit
to one of them. You can also share the workload and work in teams, or
however you work best. A status system will be available to monitor the
progression of jobs, and many more tools will become available.
So don't delay, and join the JANITOR program today! Send me an e-mail at
alex(a)relsoft.net with your name, e-mail and contact availabily (MSN,
ICQ, IRC (preferred)). A real-time communication tool will be preferred,
but I can acustom to people demanding exclusively e-mail contact (since
the JANITOR Project Site will have most of the information).
I know that many of you want to help but that the current state of the
outdatedness of the website and documentation, as well as the general
lack of directions are discouraging you. This will be a unique
experience to leave your mark in ReactOS.
Best regards,
Alex Ionescu
ReactOS JANITOR Program Manager
NOTE to Devs: The JANITOR Program is fully the child of my brain and is
a personal project, and will not use the ReactOS bandwidth, site, or
other resources unless explicit permission and agreement is made by all
developers. You will not need to do any additional task or handle
anything more and this will not affect your workload in any way.
Hello,
weiden(a)svn.reactos.com wrote:
> 1. fixed InbvPutPixels() to save the ebx register which caused bootvid
> to crash when built with optimizations
You need to save the esi register too.
ebx, esi, edi, and ebp are callee-saved registers in win32/x86.
VC++ and gcc expect external functions not to modify these registers.
http://msdn.microsoft.com/library/en-us/vclang/html/_core_argument_passing_…
| The compiler generates prolog and epilog code to save and restore
| the ESI, EDI, EBX, and EBP registers, if they are used in the function.
--
d_layer
I was in a strange mood and decided to try to implement something Alex
wanted.
I've done the leg-work on this, but need someone familiar with boot-up
and particularly smp to review this patch. I do not have access to smp,
and do not wish to break it.
This patch implements the /3G switch from within multiboot.S, which is
necessary in order to configure the page tables correctly.
I noticed some code in _main() that was processing a 3G switch on the
command-line, and I can't understand how it could possibly work because
it's not readjusting the page tables, nor does it transition to the
0xC0000000 address space that I can see, so I don't think that code
actually works. If it does, I'm glad to be proved wrong.
The patch I've written makes an assumption that lowmem is available when
application processors execute the code. I can't seem to figure out how
or where the application processor(s) actually get told to start
executing, so I don't know if this assumption is true. However, if it's
not true, if someone could point me to the code that inits the
application processors, I can configure them to pass the needed info via
%ebp or something.
Finally, I haven't actually tried booting this code. I wanted someone to
review it first for obvious blunders, or to tell me, if necessary, that
I've wasted my time ;) If I'm on the right track then, when I'm
feeling motivated enough again, I will actually try booting it.
I built Ros with ACPI=1 but the feature is not working (in real
hardware) as the computer does not go into low power state .
At boot the debug messages displayed are :
DriverBase for acpi.sys : 9ce1300
Advanced Configuration and Power Interface Bus Driver
ACPI: System firmware supports:
+------------------------------------------------------------
| Sx states: +S0 +S1 -S2 -S3 +S4 +S5
+------------------------------------------------------------
What is the status of the ACPI feature ? Is it supported actually ?
Best regards
Gerard
royce(a)svn.reactos.com wrote:
> allow oring multiple DebugPort values
>
>
> Updated files:
> trunk/reactos/boot/freeldr/freeldr/debug.c
>
Hello Royce,
A nice option would be to have the debug messages displayed in a "Debug"
window .
This will allows to redirect the debug messages to a file .
How difficult is to implement this enhancement ?
Regards
Gerard
Some urgent maintenance needs to be carried out on the electrical
installation in the building that houses the reactos.com box. To perform
this maintenance, power will be shutdown Friday night till Sunday morning.
I will be moving reactos.com web- and mailservices to a fallback box. This
should take place some time Friday. Switch back will be Sunday. The
bandwidth capacity of the fallback box is much lower than that of the main
box, so please don't plan on submitting stories to SlashDot this weekend...
Gé van Geldorp.
Hi,
I'm currently "merging" msvcrt and crtdll (again). I'll move msvcrt into
a library lib\crt and have msvcrt and crtdll link against it. Only
dllmain.c will be left in msvcrt/crtdll. Most of (99.9%) crtdll will be
dropped. It all seems to work nicely. One problem thou: I ran into some
header problems, where i relied on some stuff in include\msvcrt\string.h
but no matter what, mingw\include\string.h were included instead (and
they both defined _STRING_H_). After looking at the headers in
inlcude\msvcrt they all seem to be ripped from mingw. Does anyone know
why they were put in include\msvcrt when mingw has headers for all of
this stuff? Can i just remove them (include\msvcrt)?
I looked at many depends files and saw most files depend on many mingw
headers. Is this correct? Should we depend on mingw headers at all?
Gunnar
It seems videoprt.nostrip.sys is somewhat messed up. I've attached the
output of "objdump -p videoprt.nostrip.sys". Data Directory Entry 1 says
there's an import directory at 0x0000b000. Then down under "PE File Base
Relocations (interpreted .reloc section contents)" we find:
Virtual Address: 0000b000 Chunk size 12 (0xc) Number of fixups 2
reloc 0 offset 14 [b014] HIGHLOW
reloc 1 offset 20 [b020] HIGHLOW
When the module is loaded, the relocations are applied. This messes up the
import table, with the result that the module fails to load (copy
videoprt.nostrip.sys to \reactos\system32\drivers\videoprt.sys and boot
ReactOS). The 2 relocations given above are not present in the "normal"
videoprt.sys module.
I'm inclined to blame gcc (I'm using 3.4.1) or more likely binutils (2.15.90
20040222) for this, but before I make Filip unhappy, does anyone know if
we're doing something wrong during the build process?
Gé van Geldorp.
ion(a)svn.reactos.com wrote:
>Dynamic 3GB support, part 1. Only multiboot.S remains to be changed, all other parts of the Kernel now used KERNEL_BASE based on the command-line (Please don't use /3gb if you don't compile 3GB)
>
>
>Updated files:
>trunk/reactos/config
>trunk/reactos/ntoskrnl/include/internal/i386/mm.h
>trunk/reactos/ntoskrnl/ke/main.c
>trunk/reactos/ntoskrnl/mm/mminit.c
>
>_______________________________________________
>
>
Royce and I are currently working on making this fully dynamic. We've
got the plan set-up in our minds and it should be committed in less then
a week, unless unexpected things happen. Speaking of which, is anyone
against not making ACPI a compile-time instruction? It just makes
debugging harder, one more thing to worry about, and I don't see the
point either...I think it makes much more sense to have some kind of
ACPISupported global variable that we either set at boot-up with proper
table queries, and/or that the user can specify with an /ACPI
command-line flag.
Best regards,
Alex Ionescu
Hi,
do we need the slab cache in ntoskrnl\mm\slab.c? I've replaced the kmap
functions (ntoskrnl\mm\kmap.c) by a process local mapping (hyperspace).
The slab cache needs the mapping for a longer time and cannot use the
hyperspace mapping. I would remove the slab cache, because it is not
used by any of the kernel functions.
- Hartmut
Hi,
on a user mode exception, I get hundreds of lines like this:
(i386/exception.c:96) RtlpDispatchException()
Dumping exception registrations:
(0x0065FFE0) HANDLER (0x7C82CEAF)
(0x7FFDF000) HANDLER (0x00000000)
(i386/exception.c:96) RtlpDispatchException()
Dumping exception registrations:
(0x0065FFE0) HANDLER (0x7C82CEAF)
(0x7FFDF000) HANDLER (0x00000000)
(i386/exception.c:96) RtlpDispatchException()
Dumping exception registrations:
It needs a very large time, if ros does response again. It occurs on
real hardware. Debugprints are going over a serial line.
- Hartmut
Hervé Poussineau schrieb:
> hbirr(a)svn.reactos.com a écrit :
>
>> - Fixed the directory index of a file for FATX.
>> + ULONG startIndex = rcFcb->startIndex;
>> + if ((rcFcb->Flags & FCB_IS_FATX_ENTRY) && !vfatFCBIsRoot(Parent))
>>
>> {
>>
>> + startIndex += 2;
>> + }
>> + if(startIndex >= DirContext->DirIndex)
>> + {
>
>
> This change looks suspicious to me.
> "." and ".." don't exist on a FATX volume. They are FAT12/16/32 specific.
> Please revert related changes in create.c, dirw.c, direntry.c, fcb.c
>
> Hervé
>
> PS:
> Comment in direntry.c ("need to add . and .. entries".) is not very
> clear. It may be modified to "Need to add . and .. entries, because
> they don't exist in a FATX subdir"
> _______________________________________________
> Ros-diffs mailing list
> Ros-diffs(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-diffs
>
>
FATX doesn't have real '.' and '..' directories. But we use them on each
directory except the root. The index from fcb is also used to update the
entry of a file in its parent directory. For looking for a directory,
'.' has index 0, '..' has index 1 and 'foo' has index 2 and so on. The
real index of 'foo' is 0. We must make a difference between the real and
the search index. I've modified some parts of freeldr and usetup. I can
create and install ros on a fatx partition on a normal pc. I've also
load vfatfs on W2K. At the beginning, the wrong index has scrambled the
fatx partition.
- Hartmut
With the Mozilla ActiveX Control , I can browse "www.reactos.com" from
the Reactos Explorer as indicated before.
The link to www.reactos.com is made by explorer at start but I do not
know how to type an URL (www.google.com for example) in the Explorer
window ?
Any idea ?
Regards
Gerard
Hello,
If you are a ReactOS developer thats planning on coming to WineConf 2005 please fill out the RSVP
form at http://www.winehq.org/site/wineconf
We need to get a estimated head count so even if your not 100% sure that you will make it you can
RSVP and note that on the webstie. So far GvG and myself are planning on attending and Thomas,KJK
and fireball have said they will try to attend as well.
Thanks
Steven
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
On Mon, Jan 24, 2005 at 05:58:27PM -0600, Royce Mitchell III wrote:
> >
>
> If we even tried, the only thing we would do is alienate potential users
> of our OS, because their favorite killer app doesn't work on it.
>
Clone Microsoft's mistakes and you won't have potential users, there will be
no reason to swap to Reactos.
On Mon, Jan 24, 2005 at 08:49:17PM -0500, Richard Campbell wrote:
> If internet explorer were a 'mistake' it wouldn't have a 92% user base.
> If it isn't working, people wouldn't use it. It took quite a long time
> for a worthy competitor (firefox) to appear. Anyways, cloning internet
> explorer is outside the scope of this project. It may BE a part of
> windows, but we can install it (IE5 at least) seperately (eventually).
>
What the user base is depends on who you ask. Nobody appears to have
irrefutable up-to-date figures. And do you describe a program that CERT advises
people not to use as "works"?
But lets not argue over this. My reason for posting my commments is simply
because I think some of us are only aiming at implementing a clone whereas I
feel we should be striving to create a compatible OS that is even better, and
I get the impression from the faq on the wiki site that was one of the reasons
for this project's existence.
But on the other hand that risks becoming bogged down in discussion about how
things should be done. If at the end of the day we end up with nothing more
than an open source clone of Windows that I can hack on I will still be happy.
On Mon, Jan 24, 2005 at 04:54:58PM -0600, Royce Mitchell III wrote:
> Steven Edwards wrote:
>
> We may have to install it as both iexplore.exe as well as ibrowser.exe,
> because certain ill-behaved apps may look for iexplore.exe, and we want
> it to find the user's browser, regardless of whether they've installed
> MS's IE or are using ours.
>
But if the user's choice of browser is firefox or something else then that's
not going to work is it.
On Mon, Jan 24, 2005 at 04:54:58PM -0600, Royce Mitchell III wrote:
> We may have to install it as both iexplore.exe as well as ibrowser.exe,
> because certain ill-behaved apps may look for iexplore.exe, and we want
> it to find the user's browser, regardless of whether they've installed
> MS's IE or are using ours.
>
That should be left to the developer of the buggy app to fix. One of the
reasons Windows has problems with malware is because of developers going about
things the wrong way. They need to be taught to do things correctly, not
accommodated for.
gvg(a)svn.reactos.com schrieb:
>IoCreateFile should be passed kernelmode parameters.
>
>
>
>Updated files:
>trunk/reactos/ntoskrnl/include/internal/safe.h
>trunk/reactos/ntoskrnl/io/create.c
>trunk/reactos/ntoskrnl/io/mailslot.c
>trunk/reactos/ntoskrnl/io/npipe.c
>trunk/reactos/ntoskrnl/rtl/capture.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
Hi,
it seems that the memory for the captured parameters is never freed.
- Hartmut
Hi,
since some days ros eats up paged pool memory. I'm using cmd as login
shell. 'Make clean' on the ros source tree increase the number of paged
pool pages from 500 to more than 8000. In the past the number of paged
pool pages has never changed.
- Hartmut
ion(a)svn.reactos.com wrote:
>Bug fixes against uninitizlied variables and support for tree-wide optimization (do not try yet, crashes in bootvid).
>
>
>Updated files:
>trunk/reactos/config
>trunk/reactos/drivers/lib/ip/transport/datagram/datagram.c
>trunk/reactos/drivers/net/afd/afd/connect.c
>trunk/reactos/drivers/net/afd/afd/write.c
>trunk/reactos/drivers/net/tcpip/tcpip/info.c
>trunk/reactos/hal/halx86/generic/dma.c
>trunk/reactos/lib/epsapi/enum/drivers.c
>trunk/reactos/lib/msafd/misc/dllmain.c
>trunk/reactos/lib/shellext/slayer/slayer.c
>trunk/reactos/lib/ws2_32/misc/ns.c
>trunk/reactos/ntoskrnl/Makefile
>trunk/reactos/regtests/shared/regtests.h
>trunk/reactos/subsys/csrss/win32csr/guiconsole.c
>trunk/reactos/subsys/win32k/makefile
>trunk/reactos/tools/helper.mk
>
>
If some of you would like to turn OPTIMIZED = 1 and help me with some
of the current problems, I'd appreciate it greatly:
1) Bootvid crashes during boot logo intialization.
Booting with NOGUIBOOT gets ros to the installation page, where
2) Default selections for radio buttons and combobox do not appear, they
must now be selected manually
Apart from this glitch, driver installation and second boot were
perfect, minus the following:
3) Debug message about unhandled exception, followed by an explorer
crash related to a header file.
4) Browsing some registry keys in regedit causes regedit to crash.
I haven't noted any other problems for now, but I haven't done any deep
testing.
On the up side, this brings my little syscall benchmark to 170ms, an
additional 15% improvement. In total, this is an 80% improvement over
int2e builds. Furthermore, all of ReactOS is extremly fast. Directory
listing in cmd.exe is instant, explorer navigation as well. Menus
re-draw instantly and the whole experience is smooth. It really feels
like Windows, you have to try it to believe it.
There's been some talk on activating OPTIMIZED = 1 if (K)DBG != 1 and
all the developers on IRC were in agreement. But before such a change is
made, the bugs above need to be fixed, as well as any other possible
things which might crop up.
Best regards,
Alex Ionescu