Ros-dev October 2005

ros-dev@reactos.org

76 participants
164 discussions

by Murphy, Ged (Bolton)

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

18 years, 11 months

Re: [ros-diffs] [gvg] 18410: Terminate the new environment with a NULL pointer

by Gunnar Dalsnes

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; > } >

18 years, 11 months

Idea for a new part in headers of .rc files

by David Hinz

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

18 years, 11 months

Re: [ros-dev] ReactOS UI Team - Concept, Plan, and: help wanted

by Maritn "E.T." Misuth

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 ;).

18 years, 11 months

RE: [ros-dev] RE: Ros-dev Digest, Vol 14, Issue 25

by Murphy, Ged (Bolton)

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

18 years, 11 months

svn://svn.reactos.org/trunk/windows

by Emanuele Aliberti

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

18 years, 11 months

Re: [ros-diffs] [gdalsnes] 18403: alloc multiple of 16 bytes

by Hartmut Birr

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

18 years, 11 months

crash in usetup if an allocation size is given for a call to NtCreateFile

by Hartmut Birr

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;

18 years, 11 months

RE: [ros-svn] [turner] 18402: set to eol-style native ;)

by Casper Hornstrup

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

18 years, 11 months

Re: [ros-diffs] [gdalsnes] 18403: alloc multiple of 16 bytes

by Alex Ionescu

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

18 years, 11 months

← Newer
1
...
10
11
12
13
14
15
16
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev October 2005