- Ros-dev - ReactOS.org

FW: Klemens Friedl (frik 85)
by Ge van Geldorp 14 Oct '05

14 Oct '05

As requested: > From: nadja friedl <nadja.fiedl(a)gmx.at> > Sent: Friday, October 14, 2005 18:45 > > Hello! > I am the sister of Klemens! > He is since the 3rd. Oct. at the Austrian army and since the > 7th. Oct. ill. > So he is not allowed to come home and he has no possibility > to surf the net! > Are there any news about reactOS? > Please tell the others of my brothers illnes! > He hopes that he could come home next week! > > If you want to reply write to my email adresse and I' ll tell > him the things!

1 0

Re: [ros-diffs] [hpoussin] 18442: Don't always return STATUS_BUFFER_TOO_SMALL when an error occurs in ZwQueryValueKey.
by Alex Ionescu 14 Oct '05

14 Oct '05

hpoussin(a)svn.reactos.com wrote: >Don't always return STATUS_BUFFER_TOO_SMALL when an error occurs in ZwQueryValueKey. >The "if" was triggered because ValueInformation->DataLength is 0xcdcdcdcd at the return of the function > But that means that the memory was freed during the failure, so now the ExFreePool will run into a double-free! >Modified: trunk/reactos/ntoskrnl/io/pnpmgr.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/io/pnpmgr.c* > >--- trunk/reactos/ntoskrnl/io/pnpmgr.c 2005-10-14 13:00:18 UTC (rev 18441) >+++ trunk/reactos/ntoskrnl/io/pnpmgr.c 2005-10-14 13:04:11 UTC (rev 18442) >@@ -322,15 +322,18 @@ > > *ResultLength = ValueInformation->DataLength; > ZwClose(KeyHandle); > > > >- if (ValueInformation->DataLength > BufferLength) >- Status = STATUS_BUFFER_TOO_SMALL; >- > > > if (!NT_SUCCESS(Status)) > { > ExFreePool(ValueInformation); > return Status; > } > > > >+ if (ValueInformation->DataLength > BufferLength) >+ { >+ ExFreePool(ValueInformation); >+ return STATUS_BUFFER_TOO_SMALL; >+ } >+ > > > /* FIXME: Verify the value (NULL-terminated, correct format). */ > > RtlCopyMemory(PropertyBuffer, ValueInformation->Data, > > Please check this out in more detail... Best regards, Alex Ionescu

1 0

RE: [ros-dev] A call for 0.2.8 (Pic of Mozilla)
by Murphy, Ged (Bolton) 14 Oct '05

14 Oct '05

Richard Campbell wrote: > But how WELL does mozilla work with it? Well enough we could include it > with 0.2.8? > No, it's still full of bugs. Mozilla won't be included anyway, it's a 3rd party app. 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

3 2

Re: [ros-svn] [gdalsnes] 18427: make classes use session wide atom table. should fix bug 899
by Emanuele Aliberti 14 Oct '05

14 Oct '05

Hi Gunnar, gdalsnes(a)svn.reactos.com wrote: >make classes use session wide atom table. should fix bug 899 > > >Added files: >trunk/reactos/subsys/win32k/ntuser/session.c > > What are you plans for managing multiple instances of win32k.sys? -- :Emanuele Aliberti

3 2

termination bug
by Hartmut Birr 13 Oct '05

13 Oct '05

Hi, the termination bug is in co_DestroyThreadWindows. co_DestroyThreadWindows hangs in an endless loop which calls UserRefObjectCo. UserRefObjectCo allocates some bytes from stack with alloca. After some rounds, the kernel stack is eaten up. - Hartmut

1 0

Tenative Blocker list for 0.2.8
by WaxDragon 13 Oct '05

13 Oct '05

I've gone though bugzilla and reviewed most of the bugs, here are the ones that are blockers, might become blockers, or caveats we need to keep in mind. I'm sure we will get some real blockers when we release RC1, but this is a start. 805 - Shutdown issues http://www.reactos.org/bugzilla/show_bug.cgi?id=805 This one MUST be fixed, it affects the default install configuration. 493 - excessive repainting in tree-view controls http://www.reactos.org/bugzilla/show_bug.cgi?id=493 I would really like to see some action on this, it renders regedit near useless, and I've seen this bug in other list style controls. Pegs the CPU. 688 - AllocConsole fails on real hardware due to i8042prt http://www.reactos.org/bugzilla/show_bug.cgi?id=688 This is one of the blockers from 0.2.7 that we shipped with. Is there anything that can be done about this? Can we put some debug info into the debug builds so we can gather information? 703 - ReactOS is a fat big. Minimum mem reqs exceeded. http://www.reactos.org/bugzilla/show_bug.cgi?id=703 This one is partially fixed. 32MB installs fail on vmware due to the speed of the file copy operation. 880 - Some dlls stop display output when starting in CLI http://www.reactos.org/bugzilla/show_bug.cgi?id=880 Not a huge bug that many people see, but this is holding up hpoussin's PnP work. Discuss, WD -- <arty> don't question it ... it's clearly an optimization

1 0

Re: [ros-dev] Font problem on Japanese version of ReactOS
by tsk 13 Oct '05

13 Oct '05

Thank you for telling me that bug. I tried to use outline mplus, which doesn't include bitmap data: http://reactos-j.sourceforge.jp/up/img/083.png and tried to use Mona Font with WaxDragon's freetype.dll: http://reactos-j.sourceforge.jp/up/img/084.png Modified freetype.dll works well! But I think there still exist some bug with font rendering. One of them is a line break. ReactOS automatically insert line feeds at space. But Japanese text doesn't use space basically, so ReactOS can't insert line feeds to proper position. Many screenshots: http://reactos-j.sourceforge.jp/up/img/085.zip > mf suggested one could comment out #define > TT_CONFIG_OPTION_EMBEDDED_BITMAPS in > lib/freetype/include/freetype/config/ftoption.h to DISABLE the SBIT > support. Doing some quick testing, this allows Helmut 12pt to render > "correctly", i.e. readable. This may or may not help with the CJK > font. > > tsk, if you would like to try, I put up a modified freetype.dll at > http://waxdragon.homeip.net/~ford/freetype.dll. Give that one a try > and see if it helps with your fonts. > > WD

2 1

Firefox progress
by Ge van Geldorp 13 Oct '05

13 Oct '05

For a long time we've had problems with firefox hanging during startup. Well, I have some good news, as of r18418 it at least shows its main window, see http://www.reactos.nl/pics/ff1.png There are still lots of other problems, but I'm pretty sure we can fix those too in the next month or so. Gé van Geldorp.

4 4

A call for 0.2.8
by WaxDragon 13 Oct '05

13 Oct '05

I know how most of the devs feel about releases, but I think it's time to branch 0.2.8. After a period of instability, trunk is now showing stability. GvG and Ged reported surprising stability from the LinuxWorld demo builds, I personally had favorable results from my September State of the Repo tests. Last night I was able to build a ReactOS bootcd under r18404, and then take that bootcd and install it under qemu, under ROS! Gunnar's win32k changes have had some time to bake in and seem ok*. There have been approximately 1800 commits since 0.2.7, and I want those changes to get some general use.. I don't want to *release* now, but I want to tag the branch now, and maybe release in two weeks (which would make three months sine 0.2.7). Putting out an RC1 would give the codebase exposure to the general public, who may find problems we as devs overlook. This will also give devs and testers a change to focus on some of the big issues I see at the moment, *like this mysterious hang we see on shutdown. Also, those who wish to move forward can do so, even breaking / destabilising the tree. Giving us two or three weeks for testing release canidates will also allow for the PnP/USB and ws2_32 work to be merged in before the release. WD -- <arty> don't question it ... it's clearly an optimization

15 20

RE: [ros-dev] ReactOS UI Team - Concept, Plan, and: help wanted
by Murphy, Ged (Bolton) 13 Oct '05

13 Oct '05

Rick Langschultz wrote: > I am however writing ports for OpenLDAP, Jabber, Apache 2.0, > Tomcat, MaxDB, Postgresql, and MySQL for reactos, But there are already Win32 ports for most of, if not all of these. > but without > networking and service support my efforts are restricted to windows > 2000. That's not really a restriction. IMO, it's better to develop on Windows, get your program working perfectly and then look at testing it in ReactOS. 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

2 1

ReactOS UI Team - Concept, Plan, and: help wanted
by Aleksey Bragin 13 Oct '05

13 Oct '05

Hi, our UI Team Coordinator - mf - asked me to sent this email on his behalf, because unfortunately mails from his address doesn't reach any mailing-list. Here is the original message: From: mf <mf(a)mufunyo.net> Date: October 6, 2005 1:20:56 AM GMT+04:00 Subject: ReactOS UI Team - Concept, Plan, and: help wanted Greetings ReactOS developers and interested parties! For the unintroduced, I am your humble UI coordinator. In addition, I also made some graphics for the project. -Concept- I am here to remind you of a post that was made in the ReactOS user forum, written by crappish (Mikko Tikkanen). In it the author wrote of the need of a consistent user interface, the need of people that actually have knowledge of such things, and how these people would have to be in charge of enforcing such an interface. They should be familiar with Windows, know how to make things accessible and newbie- friendly, and have enough creativity to improve on existing concepts. In addition to that, there should be someone who represents this team and can interface it with the rest of the project, and make sure everything is the way everyone wants it to be. Now, this representative has been chosen. But there is no team to back him up! -Recruiting- So getting down to business. The UI team is recruiting two kinds of people. Primarily: Programmers who have sufficient knowledge to hack other people's code, even if said code is rooted deeply in system libraries. Skill in writing user interfaces and piecing together dialog resources. No advanced skills beyond that required. This is most important, since developers in this category can get straight to business and get started on improving ReactOS. Secondarily: Interface concept designers who have advanced knowledge of human interfacing, easy access, logical positioning, and the creativity to improve and expand on existing ideas. This is a secondary category because a) right now there is little to do in this respect, b) there are already two (counting Mikko?) of these people in ReactOS, and c) for every 1 concept designer, there can be up to 10 implementing developers. Even more appreciated, would be someone who fits both gloves and can write code AND design interfaces. Sadly, experience proves that these two traits don't usually come together in one person. And! Just as important, though not actively recruited, I welcome icon designers, graphic designers, font designers (that includes you, wierd_w!), sound effect samplers, and programmers willing to implement missing UI features (think of things such as extended cursor/icon support, alpha blitting, runtime freetype configuration, recycle bin functionality, control panel, autorun support, etc), on individual application (mail me at mf(a)mufunyo.net). -Plan- The plan(tm) to kickstart the UI team is as follows: Our first goal will be to make the surface experience of ReactOS familiar. Surface in this context means the things a user will see during and after bootup. This mainly involves modifying explorer; to display a consistent and familiar start menu, and to show a friendly explorer when My Computer or the Explore link is opened. This means making all the surface icons consistent (my task), modifying explorer's interface (the 'programmer' category), and figuring out the best layout for the start menu (the 'designer' category). There is no plan past this first task, because I cannot predict how small or big the team is going to be, what feedback we are going to get, and how fast things will move. And that's it for my first big announcement. I hope this will get some discussion going, and some balls rolling. I would also like to take this opportunity to request a mailing list for the UI team, this should have been set up right after the coordinator vote was over, but it wasn't-- so to whoever's in charge of that, I count on you. Thanks. Please reply to this mail only on the general list or to me in person (if you're not on the list and only get digests), it is only crossposted in ros-dev to get a wider range of attention. Thanks for reading, mf.

9 13

Problem with VMware Workstation 5.5
by Mike Swanson 12 Oct '05

12 Oct '05

for the most part, all is well. However, upon the installation of video drivers using the VMware Tools ISO, ReactOS fails to install the driver. I believe this is simply because of a new directory structure to accomodate both 32-bit and 64-bit Windows operating systems.. 32-bit driver: D:\program files\VMware\VMware Tools\Drivers\video\winnt2k\32Bit 64-bit driver (probably not wanted unless someone's doing a x86_64 port): D:\program files\VMware\VMware Tools\Drivers\video\winnt2k\64Bit -- Mike

1 2

RE: [ros-dev] A call for 0.2.8
by Murphy, Ged (Bolton) 12 Oct '05

12 Oct '05

Wow, there's no flies on you ;) -----Original Message----- From: WaxDragon [mailto:waxdragon@gmail.com] Sent: 12 October 2005 14:43 To: ReactOS Development List Subject: Re: [ros-dev] A call for 0.2.8 I was hoping to get it branched today, do a baseline test and have an RC1 for this weekend. If Brandon does the release, that would help me out. ************************************************************************ 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

7 6

Font problem on Japanese version of ReactOS
by tsk 12 Oct '05

12 Oct '05

I made Japanese version of ReactOS. Following is all that I have done. 1) add jpn.nls to \lib\kernel32\nls\ 2) modify \lib\kernel32\locale_rc.rc 3) add Japanese font to \media\fonts\ 4) add next line to \bootdata\hivesft.inf HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\SysFontSubstitutes","MS UI Gothic",0x0000 0000,"FontName" 5) add next line to \bootdata\packages\reactos.dff media\fonts\FontName.ttf 3 6) modify locale settings at \bootdata\hivesft.inf and hivesys.inf HKCU,"Control Panel\International","Locale",0x00000000,"0411" HKLM,"SYSTEM\CurrentControlSet\Control\NLS\Language","Default",0x00000000,"0411" HKLM,"SYSTEM\CurrentControlSet\Control\NLS\Language","InstallLanguage",0x00000000,"0411" Now please look at these screenshots. http://reactos-j.sourceforge.jp/up/img/081.png http://reactos-j.sourceforge.jp/up/img/082.png The former uses mona http://monafont.sourceforge.net/index-e.html The latter uses mplus http://www.kaoriya.net/#BDFM+ I'm very sad... Is ReactOS able to handle Japanese font properly?

3 3

Re: [ros-svn] [ekohl] 18383: First shot at CreateServiceW. It crashes due to a bug (aka missing feature) in widl. = ROS BUILD FAILED
by Gge 12 Oct '05

12 Oct '05

ekohl(a)svn.reactos.com wrote: > First shot at CreateServiceW. It crashes due to a bug (aka missing feature) in widl. I'm going to fix it as soon as possible. > > > Updated files: > trunk/reactos/include/idl/svcctl.idl > trunk/reactos/lib/advapi32/service/scm.c > trunk/reactos/subsys/system/services/database.c > trunk/reactos/subsys/system/services/rpcserver.c > trunk/reactos/subsys/system/services/services.c > trunk/reactos/subsys/system/services/services.h > Hello, This change brokes Ros - It fails to build with the following errors : [CC] lib\advapi32\service\eventlog.c [CC] lib\advapi32\service\scm.c lib\advapi32\service\scm.c: In function `CreateServiceW': lib\advapi32\service\scm.c:271: warning: implicit declaration of function `ScmrCreateServiceW' mingw32-make: *** [obj-i386\lib\advapi32\service\scm.o] Error 1 R18382 builds fine Regards Gge

4 4

RE: [ros-dev] A call for 0.2.8
by Murphy, Ged (Bolton) 12 Oct '05

12 Oct '05

Robert wrote: > This would still work out with my plans. > I'll be able to do this release. BTW I intended to document and > rbuildify (or the like) the process Can we branch for this sooner rather than later. What about this weekend? ************************************************************************ 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

2 1

Re: [ros-diffs] [gvg] 18410: Terminate the new environment with a NULL pointer
by Gunnar Dalsnes 12 Oct '05

12 Oct '05

There are probably dozens of bugs like that lurking around in crt, exposed by malloc not zeroing memory anymore... gvg(a)svn.reactos.com wrote: > Terminate the new environment with a NULL pointer > > Modified: trunk/reactos/lib/crt/misc/environ.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/crt/misc/environ.c* > > --- trunk/reactos/lib/crt/misc/environ.c 2005-10-12 08:38:45 UTC (rev 18409) > +++ trunk/reactos/lib/crt/misc/environ.c 2005-10-12 13:00:34 UTC (rev 18410) > @@ -178,6 +178,7 @@ > > return original_environment; > } > } > > + *newenvptr = NULL; > > > return newenv; > } >

2 1

Idea for a new part in headers of .rc files
by David Hinz 12 Oct '05

12 Oct '05

Hey guys, when I just translated format, I stunbled over one thing: What if somebody changed the content of a string after I translated it? After some minutes, I had a easy solution for that problem: The En.rc gets a little line in it's head-comment with a revision number. Each time somebody changes or adds a string in the En.rc, he sets the revision number +1 and so all translators have an easy to control indicator, if they need to translate something or not. But I think one thing should be clear, if there just has been corrected a spelling mistake and not something important, the revision number won't be touched. Now some example headers: in the EN.rc: /* * Moved all hardcoded strings to En.rc. * By Magnus Olsen 2005 * * Revision: 1 */ in my De.rc: /* * Moved all hardcoded strings to En.rc. * By Magnus Olsen 2005 * First German Translation by David Hinz 20051010 * * Translated Revision 1 of En.rc */ This is just an idea, but I think this could save a lot of work on bigger applications than format... Greets, David Hinz

3 3

Re: [ros-dev] ReactOS UI Team - Concept, Plan, and: help wanted
by Maritn "E.T." Misuth 12 Oct '05

12 Oct '05

To my knowledge, it is completely posible to write helper apps in JavaScript to function with XUL. At least as extension modules for apps already using the whole thing. For example I think that ChatZilla extension for mozilla is written that way, in pure JavaScript. But if XUL can be used as a core part of some system's dialog/windows rendering I think it is completely possible to create relatively simple facility to have complete standalone apps in JavaScript. It's a long time since I've played with XUL, but if you have FireFox, you can start to play with it right now, and create for example simple dialogs & windows with radio buttons etc using that language and CSS styles. PS: Yes it was an accindent, I wanted to send the mail to the list, sorry ;).

1 0

RE: [ros-dev] RE: Ros-dev Digest, Vol 14, Issue 25
by Murphy, Ged (Bolton) 12 Oct '05

12 Oct '05

I'm not quite sure what everyone is getting at here. Every file has it's entire history logged, easily accessible through your local tree under the context menu, or through Viewcvs on the web. Changes also go out through the svn mailing list. Any closer queries can me viewed via 'diff'ing to any revision you want. However, it would be easy to write a quick tool to assess local timestamps after svn updates for set file types. This would quickly tell you what has changed without the need for viewing the svn logs. Ged. -----Original Message----- From: David Hinz [mailto:post.center@gmail.com] Sent: 12 October 2005 13:12 To: ReactOS Development List Subject: Re: [ros-dev] RE: Ros-dev Digest, Vol 14, Issue 25 Well, the thing is I wanted to have something that makes it very easy to see, if something has changed since the last time I translated that file. Watching the svn all the time is not that easy than just looking at a number. There could also be a little helper app that scans all .rc files in my language and all en.rcs for revision differences and shows me, where I have to translate something. Then I can look in the svn what actually has been changed. It just makes things easier for translators. Greets, David Hinz ************************************************************************ 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 0

svn://svn.reactos.org/trunk/windows
by Emanuele Aliberti 11 Oct '05

11 Oct '05

Should I call for a VOTE, or is it OK having a top level module for all Win32 related pieces? Please, comment. Thank you in advance. -- :Emanuele Aliberti

6 11

Re: [ros-diffs] [gdalsnes] 18403: alloc multiple of 16 bytes
by Hartmut Birr 11 Oct '05

11 Oct '05

gdalsnes(a)svn.reactos.com wrote: > alloc multiple of 16 bytes > What was the reason for this change? - Hartmut

2 1

crash in usetup if an allocation size is given for a call to NtCreateFile
by Hartmut Birr 11 Oct '05

11 Oct '05

Hi, I've done some little changes in usetup for optimisation. One thing is the decompressing of files from a cabinet container. If the destination file exist, it is created with the create disposition FILE_OVERWRITE and without a pointer to the allocation size. If I add an allocation size pointer (cabinet.c.diff), usetup does crash after copying of all files and creating the registry. (ntoskrnl\ke\exception.c:94) KiRaiseException (ntoskrnl\ke\i386\exp.c:1306) Unhandled UserMode exception, terminating thread Exception: -1160049408(0) Processor: 0 CS:EIP 1b:12000 ????? cr2 66f924 cr3 56a000 Proc: 8094a1f0 Pid: 5c <smss.exe> Thrd: 80954088 Tid: 60 DS 23 ES 23 FS 3b GS 0 EAX: 00012000 EBX: 00000001 ECX: 0066fc18 EDX: 7c90a479 EBP: 0066ff54 ESI: 00000004 ESP: 807ebd64 EDI: 0066fc28 EFLAGS: 00000216 Frames: <smss.exe:741b> subsys/system/usetup/console.c:660 <smss.exe:19c41> subsys/system/usetup/usetup.c:3321 <smss.exe:1a65e> subsys/system/usetup/usetup.c:3781 <0> The address of the crash has nothing to do with the decompressing of the install files. If I change IoCreateFile file a little bit, that the allocation size pointer isn't read (file.c.diff), usetup didn't crash. Has someone an idea what is wrong? - Hartmut Index: subsys/system/usetup/cabinet.c =================================================================== --- subsys/system/usetup/cabinet.c (Revision 18300) +++ subsys/system/usetup/cabinet.c (Arbeitskopie) @@ -859,6 +859,7 @@ UnicodeString.Buffer = DestName + wcslen( DestName ); UnicodeString.Length = 0; RtlAnsiStringToUnicodeString( &UnicodeString, &AnsiString, FALSE ); + MaxDestFileSize.QuadPart = Search->File->FileSize; /* Create destination file, fail if it already exists */ RtlInitUnicodeString(&UnicodeString, @@ -884,7 +885,7 @@ 0); if (!NT_SUCCESS(NtStatus)) { - DPRINT("NtCreateFile() failed (%S) (%x).\n", DestName, NtStatus); + DPRINT1("NtCreateFile() failed (%S) (%x).\n", DestName, NtStatus); /* If file exists, ask to overwrite file */ if (OverwriteHandler == NULL || OverwriteHandler(Search->File, DestName)) @@ -894,7 +895,7 @@ GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE, &ObjectAttributes, &IoStatusBlock, - NULL, + &MaxDestFileSize, FILE_ATTRIBUTE_NORMAL, 0, FILE_OVERWRITE, @@ -903,7 +904,7 @@ 0); if (!NT_SUCCESS(NtStatus)) { - DPRINT("NtCreateFile() failed 2 (%S) (%x).\n", DestName, NtStatus); + DPRINT1("NtCreateFile() failed 2 (%S) (%x).\n", DestName, NtStatus); return CAB_STATUS_CANNOT_CREATE; } } @@ -913,7 +914,6 @@ return CAB_STATUS_FILE_EXISTS; } } - MaxDestFileSize.QuadPart = Search->File->FileSize; NtStatus = NtCreateSection(&DestFileSection, SECTION_ALL_ACCESS, 0, @@ -964,7 +964,10 @@ } else { +// memcpy(&FileBasic.CreationTime, &FileTime, sizeof(FILETIME)); memcpy(&FileBasic.LastAccessTime, &FileTime, sizeof(FILETIME)); +// memcpy(&FileBasic.LastWriteTime, &FileTime, sizeof(FILETIME)); +// memcpy(&FileBasic.ChangeTime, &FileTime, sizeof(FILETIME)); NtStatus = NtSetInformationFile(DestFile, &IoStatusBlock, @@ -1050,6 +1053,7 @@ Status = CAB_STATUS_SUCCESS; UnmapDestFile: NtUnmapViewOfSection(NtCurrentProcess(), DestFileBuffer); +// NtFlushBuffersFile(DestFile, &IoStatusBlock); CloseDestFileSection: NtClose(DestFileSection); CloseDestFile: Index: ntoskrnl/io/file.c =================================================================== --- ntoskrnl/io/file.c (Revision 18300) +++ ntoskrnl/io/file.c (Arbeitskopie) @@ -787,7 +787,11 @@ sizeof(ULONG)); if(AllocationSize != NULL) { - SafeAllocationSize = ProbeForReadLargeInteger(AllocationSize); + ProbeForRead(AllocationSize, + sizeof(LARGE_INTEGER), + sizeof(ULONG)); + SafeAllocationSize.QuadPart = 0 /* AllocationSize->QuadPart */; +// SafeAllocationSize = ProbeForReadLargeInteger(AllocationSize); } else SafeAllocationSize.QuadPart = 0;

1 0

RE: [ros-svn] [turner] 18402: set to eol-style native ;)
by Casper Hornstrup 11 Oct '05

11 Oct '05

Open C:\Documents and Settings\...\Application Data\Subversion\config. Make sure the following is in there: [miscellany] enable-auto-props = yes [auto-props] *.c = svn:eol-style=native *.h = svn:eol-style=native *.S = svn:eol-style=native *.sh = svn:eol-style=native;svn:executable *.rc = svn:eol-style=native *.mc = svn:eol-style=native *.asm = svn:eol-style=native *.cpp = svn:eol-style=native *.cxx = svn:eol-style=native *.txt = svn:eol-style=native *.xml = svn:eol-style=native *.ini = svn:eol-style=native *.inf = svn:eol-style=native *.def = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.gif = svn:mime-type=image/gif *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg *.bmp = svn:mime-type=application/octet-stream *.ico = svn:mime-type=application/octet-stream *.ttf = svn:mime-type=application/octet-stream *.nls = svn:mime-type=application/octet-stream *.mp3 = svn:mime-type=application/octet-stream *.wav = svn:mime-type=application/octet-stream Makefile = svn:eol-style=native DON'T add: * = svn:eol-style=native or Magic Things (TM) will happen ;-) Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.org [mailto:ros-svn-bounces@reactos.org] On Behalf Of > turner(a)svn.reactos.com > Sent: 10. oktober 2005 21:09 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [turner] 18402: set to eol-style native ;) > > set to eol-style native ;) > > > Updated files: > trunk/reactos/subsys/system/cmd/readme2.txt > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-svn

4 4

Re: [ros-diffs] [gdalsnes] 18403: alloc multiple of 16 bytes
by Alex Ionescu 11 Oct '05

11 Oct '05

gdalsnes(a)svn.reactos.com wrote: > alloc multiple of 16 bytes > Modified: trunk/reactos/lib/crt/stdlib/malloc.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/crt/stdlib/malloc.c* > --- trunk/reactos/lib/crt/stdlib/malloc.c 2005-10-10 19:08:57 UTC (rev 18402) > +++ trunk/reactos/lib/crt/stdlib/malloc.c 2005-10-10 20:18:07 UTC (rev 18403) > @@ -25,6 +25,10 @@ > #include <stdlib.h> > #include <malloc.h> > > > + > +/* fixme: should have this in common header */ > +#define ROUND_UP(a,b) ((a + (b-1)) & ~(b-1)) > helper.s > + > > extern HANDLE hHeap; > > /* > @@ -32,7 +36,7 @@ > > */ > void* malloc(size_t _size) > { > > - return HeapAlloc(hHeap, HEAP_ZERO_MEMORY, _size); > > + return HeapAlloc(hHeap, 0, ROUND_UP(_size, 16)); > > } > > /* > @@ -48,7 +52,7 @@ > > */ > void* calloc(size_t _nmemb, size_t _size) > { > > - return HeapAlloc(hHeap, HEAP_ZERO_MEMORY, _nmemb*_size); > > + return HeapAlloc(hHeap, HEAP_ZERO_MEMORY, ROUND_UP(_nmemb*_size, 16) ); > > } > > /* > @@ -57,8 +61,8 @@ > > void* realloc(void* _ptr, size_t _size) > { > if (!_ptr) > > - return HeapAlloc(hHeap, 0, _size); > - return HeapReAlloc(hHeap, 0, _ptr, _size); > > + return HeapAlloc(hHeap, 0, ROUND_UP(_size, 16)); > + return HeapReAlloc(hHeap, 0, _ptr, ROUND_UP(_size, 16)); > > } > > /* > @@ -66,7 +70,7 @@ > > */ > void* _expand(void* _ptr, size_t _size) > { > > - return HeapReAlloc(hHeap, HEAP_REALLOC_IN_PLACE_ONLY, _ptr, _size); > > + return HeapReAlloc(hHeap, HEAP_REALLOC_IN_PLACE_ONLY, _ptr, ROUND_UP(_size, 16)); > > } > > /* > Ever heard of HEAP_ALIGN_16? Best regards, Alex Ionescu

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev