- Ros-dev - ReactOS.org

by Bernd Blaauw

Is there going to be a new release candidate of ReactOS version 0.3.3? I tested it very shortly and was very impressed with how it looked in comparison to version 0.3.0. Is there a list of known bugs as feedback from 0.3.3rc1 testers? Searching through Bugzilla might be a bit too much :). Anyway, the issues I experience in VMware 6.00 on WinXP Pro x64 host so far are: * diskette drive not visible (and/or working). Ever since 0.2.8 or so? * shutdown does not close the virtual machine (might be improper shutdown). Screen goes all black and need to enter VMware menu to shutdown the ReactOS virtual machine. Is the AUTORUN.INF by now the only file on the root of the CD? icons and readme files can go in subdirectories I guess, which makes adding ReactOS to multi-installation CDs a lot easier (a CD/DVD containing setup or LiveCD of various operating systems, mostly using the Isolinux bootloader for a frontend menu and chainloading bootsectors). I've not extensively tested the RC1 on for example if it still can complete installation and bootup with 32MB or less RAM installed (VMware allows anywhere from 4MB to 8GB in increments of 4MB, Bochs/Qemu allow 1MB increases). A resolved item I noticed in this new release was the ability to enter digits for the computername, wasnt possible previously in 0.3.0 or 0.3.1. ReactOS is getting interesting by now..a Win32 operating system with a size of about 50MB and capable of playing huge games sooner or later. Looks like a blessing to my limited size (16GB) DRAM based solid state disk.

18 years

4
4
0 0

[ros-diffs] [jimtabor] 22523: GetGlyphOutline, large wine port. Still testing.

by James Tabor

Hi, I have it half way done. Run the test program and you can see. Program works in W2k, XP and Wine. mingw32-gcc -mwindows -Os GetGlyphOutline.c -o ggo.exe I stopped messing with it two weeks ago, I needed to work on something else. When testing you can select the alphanumeric character with the keyboard. The original program had "a" but I changed it to "L" something simple to draw at first. You will see the problem. The test program from Dr. Dobb's Journal http://www.ddj.com/184409154?pgno=12 Thanks, James Runs and hides~

18 years

1
1
0 0

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?

by theUser BL

>Personal preference. >Wine are nearing to a 1.0 product and are very careful about what code >enters their repository. >ReactOS does not currently meet their strict policy. > >If you want to get code into Wine, you must submit your patches with test >cases and if required, relevant links to documentation. I have also ask the question on the WINE-mailinglist. The answer at http://www.winehq.org/pipermail/wine-devel/2007-August/058929.html looks like, that the test-suites are not the only reason. Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

18 years

3
2
0 0

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?

by Aleksey Bragin

As I already said, the difference between ReactOS and WINE, as it's written in that Wine mailing list, is that ReactOS "is known" [by some] for reversing MS binaries, and Wine is not known for reversing MS binaries (though it does not imply ReactOS is always doing it, and Wine did [does] not reverse engineer). Also, Wine is not "Open Source community", it is *part* of Open source community, as are thousands of other projects, which somehow form the general perception of projects. WBR, Aleksey Bragin. On Aug 29, 2007, at 7:01 PM, Marc Piulachs wrote: > > Does it mean ReactOS is not respected/trusted among the Open Source > community for disassembling Microsoft binaries? > > I don't know if this accusation is really true or not but if it's > not I > think it's even worse because that means that something is failing > (probably > communication) between the project and the OS community. Doing > nothing about > that is IMHO a very bad idea. > > I think it deserves some deep reflection and a *serious* strategy > to change > that general opinion. Earn respect is a KEY thing to do if the > project wants > to attract new developers. > > My two cents, > Marc

18 years

1
0
0 0

Re: [ros-dev] Will ROS and WINE still be steady be synchronized ?

by Aleksey Bragin

Wine, as every other project, is free to set their own rules for accepting patches. If members of our development team can do anything to help Wine - we are glad to. However, they seem to want to stick to only their own devs' contribution (mainly). With the best regards, Aleksey Bragin. On Aug 29, 2007, at 4:54 PM, theUser BL wrote: >> Personal preference. >> Wine are nearing to a 1.0 product and are very careful about what >> code >> enters their repository. >> ReactOS does not currently meet their strict policy. >> >> If you want to get code into Wine, you must submit your patches >> with test >> cases and if required, relevant links to documentation. > > I have also ask the question on the WINE-mailinglist. > The answer at > http://www.winehq.org/pipermail/wine-devel/2007-August/058929.html > looks like, that the test-suites are not the only reason. > > > Greatings > theuserbl

18 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [hpoussin] 28603: qsort() prototype in stdlib.h doesn't specify that callback function must be __cdecl

by Alex Ionescu

O rly? _CRTIMP void __cdecl qsort(__inout_bcount(_NumOfElements * _SizeOfElements) void * _Base, On 8/27/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > > Author: hpoussin > Date: Mon Aug 27 19:26:39 2007 > New Revision: 28603 > > URL: http://svn.reactos.org/svn/reactos?rev=28603&view=rev > Log: > qsort() prototype in stdlib.h doesn't specify that callback function must > be __cdecl > > Modified: > trunk/reactos/lib/rtl/bitmap.c > > Modified: trunk/reactos/lib/rtl/bitmap.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/bitmap.c?rev=28603… > > ============================================================================== > --- trunk/reactos/lib/rtl/bitmap.c (original) > +++ trunk/reactos/lib/rtl/bitmap.c Mon Aug 27 19:26:39 2007 > @@ -36,7 +36,6 @@ > > static > int > -__cdecl > NTDLL_RunSortFn(const void *lhs, > const void *rhs) > { > > > -- Best regards, Alex Ionescu

18 years

2
1
0 0

Wine-WordPad instead of ROS-WordPad?

by theUser BL

Hi! Yesterday I have downloaded and tried out the lastest vrsion of Wine. Version 0.9.44. In the annoncement of that release there stand "Improvements to the builtin WordPad". So I have also tried ot its WordPad and it looks better then the ROS-Notepad. So wouldn't it a trhought to use WINEs WordPad instead of ROS one? And will the sources of WINE and ROS steady be synchronized ? Seems, that WINE uses an old version of cards.dll. The notepad from ROS and WINE is different and so on. _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

18 years

3
3
0 0

Re: [ros-dev] State of 0.3.3

by carlo.bramix

Hello. If it's possible, I would ask to apply the patch posted at bug #2494 before releasing 0.3.3 (RC2 or Final), so I will be able to remove my backup copy of regedit... Sincerely, Carlo Bramini. Colin Finck wrote: > Hello, > > As you probably saw, I recently rebranched 0.3.3 and made some changes to > it. > Now I'm at the point, where *I* think that it's ready. > > I don't know if anyone else has any specific plans for 0.3.3, so I'm just > asking here now. > Otherwise, I think we could simply release the current branch as RC2 or even > REL. But also if we release it as RC2 now, what are the plans for the REL > version then? > > Please also think of our planned 2-month release cycle. > I know that these are just estimated dates, where users *can* expect a > release and I myself said this a couple of times as well, but we already > skipped 0.3.2, so we shouldn't miss the "deadline" for 0.3.3 now. > > Regards, > > Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev at reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

18 years

1
0
0 0

ENUMFONTDATAW structure

by Timo Kreuzer

I agree with the complete structure itself, but I have some issues with the way it is implemented atm. 1.) the member ulOffsetTM: If it is an offset one would guess it would be an offset from the beginning of the struct, but it isn't. It's relative to dwFontType. I would interpret it more as a cbSize member of an internal variable size struct., that comes before dwFlags (see below) / textmetric 2.) The current definition has a member enfdi, wich follows after a variable size struct. IMO this member should be removed, as it doesn't have a constant offset. It implies that you can simply access it, but you cannot, if the designvektor has any entries. It should be commented out to prevent misuse. 3.) The enfdi struct doesn't really make sense to me. The dwReserved members are not like axlReserved a constant. It looks more like some flags or it might be code page related. With this structure the OffsetTm member points to a substruct of a struct, that doesn't seem right to me. So here is my version: I also use INT versions of structs with a [0] array, so it matches the data, when no additional stuff is present But as we always have to consider our structs as variable length we do not really need them. In any case we have to parse through the struct. We can then typecast the pointers to the original structs and all's well. typedef struct _AXELISTINTW { DWORD axlReserved; DWORD axlNumAxes; AXISINFOW axlAxesInfo[0]; } AXELISTINTW, *PAXELISTINTW; typedef struct _ENUMTEXTMETRICINTW { NEWTEXTMETRICEXW etmNewTextMetricEx; AXELISTINTW etmAxesList; } ENUMTEXTMETRICINTW, *PENUMTEXTMETRICINTW; typedef struct { DWORD cbSize; DWORD dwFontType; ENUMLOGFONTEXW elfex; DESIGNVECTORINT dv; // variable position, might be dv.dvValues[0], if DESIGNVECTORINT was declared with dvValues[1] // I didn't yet manage to get info with dvNumAxes > 0 // DWORD dwReserved; } ENUMFONTDATAINTW, *PENUMFONTDATAINTW; typedef struct _ENUMFONTDATAW { DWORD cbSize; ENUMFONTDATAINTW efdi; // Those are not real members as they don't have a constant pos in the struct // DWORD dwFlags; // ENUMTEXTMETRICINTW etmi; } ENUMFONTDATAW, *PENUMFONTDATAW;

18 years

2
1
0 0

Re: [ros-dev] Open source drivers for (S)ATA and VESA

by Aleksey Bragin

Hi, Magnus already commented about the video driver (if his changes were good, he would send us patches). However, uniata is not that bad, I was going to review it some time after 0.3.3, and if the code is allright, it could be included. IIRC, scsiport needs some improvement in order to fully support the uniata driver. WBR, Aleksey Bragin. On Aug 27, 2007, at 8:42 PM, Timo Kreuzer wrote: > Hi, I just found some interesting stuff: > > Universal ATA driver (http://alter.org.ua/soft/win/uni_ata/) > - generic NT driver for DMA/UDMA ATA / SATA with source code > > Universal VESA driver > - based on ReactOS vbemp.sys > - works on all windows NT and ReactOS > the author has been working on this until very recently, so it > might be > better than our current driver > > Timo

18 years

1
0
0 0

Open source drivers for (S)ATA and VESA

by Timo Kreuzer

Hi, I just found some interesting stuff: Universal ATA driver (http://alter.org.ua/soft/win/uni_ata/) - generic NT driver for DMA/UDMA ATA / SATA with source code Universal VESA driver - based on ReactOS vbemp.sys - works on all windows NT and ReactOS the author has been working on this until very recently, so it might be better than our current driver Timo

18 years

2
1
0 0

State of 0.3.3

by Colin Finck

Hello, As you probably saw, I recently rebranched 0.3.3 and made some changes to it. Now I'm at the point, where *I* think that it's ready. I don't know if anyone else has any specific plans for 0.3.3, so I'm just asking here now. Otherwise, I think we could simply release the current branch as RC2 or even REL. But also if we release it as RC2 now, what are the plans for the REL version then? Please also think of our planned 2-month release cycle. I know that these are just estimated dates, where users *can* expect a release and I myself said this a couple of times as well, but we already skipped 0.3.2, so we shouldn't miss the "deadline" for 0.3.3 now. Regards, Colin

18 years

5
4
0 0

Megalithic subjects

by carlo.bramix

Hello, I don't want to make problems in any way but... is it possible to make the titles of the emails a bit shorter when it could be done? Some of them are really difficult to read and, in my opinion, the body of the email exists for writing more detailed explanations. Sincerely, Carlo Bramini

18 years

1
0
0 0

[ros-diffs] [cfinck] 28526: rbuild enhancements by Marc Piulachs

by James Tabor

Hi! r28526 broke bootcd Sorry, James

18 years

1
0
0 0

ReactOS and Sound cards.

by James Courtier-Dutton

Hi, How much work would it take to support a soundcard in ReactOS? I would like to use it to help me reverse engineer a sound card to get it working in Linux. Kind Regards James

18 years

2
1
0 0

Re: [ros-dev] IoCheckEaBufferValidity

by Aleksey Bragin

Reformatted, improved and committed (28506 & 28507). Thanks for contribution. WBR, Aleksey Bragin. On Aug 22, 2007, at 1:53 AM, netzimme(a)aim.com wrote: > > > Sorry the patch was wrong. I have forgot to change the function name. > > > Thanks > Daniel Zimmermann

18 years

1
0
0 0

[Fwd: [ros-kernel] ReactOS status report for 10/12/1998]

by James Tabor

Hi! More voices from the past. James -------- Original Message -------- Subject: [ros-kernel] ReactOS status report for 10/12/1998 Resent-Date: Tue, 13 Oct 1998 00:21:40 -0500 Resent-From: ros-kernel(a)sid-dis.com Date: Mon, 12 Oct 1998 22:24:40 -0700 From: rex <rex(a)lvcablemodem.com> Reply-To: <ros-kernel(a)sid-dis.com> To: ros-kernel(a)sid-dis.com <ros-kernel(a)sid-dis.com> ReactOS status report for Monday, October 12th 1998 Current Kernel Release is 0.0.12 Working drivers: Driver Version ------------ ------- FS/Minix 0.0.1 IDE 0.1.2 Keyboard 0.0.4 Null 0.0.1 Parallel 0.0.1 SDisk 0.0.1 Welcome to Brian and good luck to him as he settles in and learns of the vast intracacies and subtleties of the ReactOS kernel. Benoit Papillault has taken on the task of the PE program loader. Francois Asselin sent me a response indicating he doesnt currently have time to work on the schedular due to his studies. Perhaps he should move to the inactive list. An attempt to send mail to Iwan Fatahi's mail account bounced. Iwan, if you're there, perhaps you can let me know if you're working on anything, and let the webmaster know your current email address. I've been sending messages to various people on the kernel members listing asking for status on their piece of the system. If I do not get a responce after three tries I'll assume that person is busy for the time being, send the info to the appropriate lead and remove their name from the status report. If anyone thinks that's not an appropriate thing to do let me know. Development Status: Boot Loader No Status. DOS Loader No Status. Kernel: Brain Palmer I/O Manager: No Status. Memory Management No Status. Process Management: No Status. Security Manager No Status. Filesystem Interface No Status. Miniport Drivers No Status. Local Procedure Calls: Giovanni Tapang No Status. System Calls: Networking support: Arindam Das and Jason Eager No Status. Plug and Play support No Status. PCI No Status. Registry No Status. ACPI power managment No Status. Loader for PE executables: Benoit Papillault No status. Ports to other platforms No Status. Drivers: Floppy: Rex Jolliff No status. IDE: Rex Jolliff Worked on bug reports: Driver crashes on detection of Secondary/Slave with ATAPI CDROM connected. (I believe I found the problem, but need an updated test system to be sure) Driver creates incorrect symbolic link for 2nd drive. (I'm not sure this bug exists, as I can't reproduce it.) Sound: Robert Bergkvist (FragDance Galore) No status. VFAT: Jason Filby First release currently in testing. Other Filesystems: Dennis Varouxis and Etienne Cochard No status. Console No status. Mouse: Jason Filby No status. Network No status. Serial No status. Video: Conor Stokes, Iwan Fatahi and Jerome Davadilla Mail sent to Iwan Fatahi requesting status bounced. System Libraries: Stub Generator No Status. KERNEL32 No Status. Identification of remaining libraries No Status. Milestones: Working: Kernel R13 Brain Palmer Est: 01/01/1999 Boot loader improvements NASM new release compatability Buffered I/O bugfix VFAT R1 Jason Filby Est: 01/01/1999 IDE R2 Rex Jolliff Est: 10/31/1998 Second release will fix the 255 sector read limitation and add timeout detection code. Complete: IDE R1 Rex Jolliff Est: 10/15/1998 Act: 09/20/1998 First release will locate up to 8 drives, make available devices for the raw device and all dos compatable partitions and read and write using non DMA I/O. Kernel R12 David Welch Est: 09/31/1998 Act: 10/04/1998 New: Multiple processes System calls (this is already working) Improved multithreading support Support for additional filesystem operations Some support for disk caching On Hold: Killed:

18 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [cfinck] 28423: - Always include"wine/unicode.h" before all other headers, when we need the wchar_t type. unicode.h includes windef.h, which includes winnt.h, which has the handling for the wchar_t type. As it's the firstinc

by Steven Edwards

On 8/19/07, Colin Finck <mail(a)colinfinck.de> wrote: > These changes were made to properly compile ReactOS under a Mac OS X host. > They have nothing to do with MSVC or the Microsoft SDK headers. Sorry I was not clear about what I meant in my rant and sounded bitchy > Mac OS X defines its own wchar_t type in "ctype.h". But it uses _WCHAR_T for > reporting that the type has been defined and not _WCHAR_T_DEFINED like > Windows does. > This is why I needed to add a handling for _WCHAR_T in "winnt.h". > But if "ctype.h" is now included before "winnt.h", these changes don't have > any effect. This is why I changed the header order. > > Of course, there might be other "solutions" to this problem (like adding all > possible definitions that wchar_t has been defined into the Makefile), but > this is the simplest one. > And I see no reason not to do this for fixing this problem. It makes anyone doing a diff have more stuff to have to workaround. There are constantly minor updates and fixes to the unicode tables in Wine because Microsoft did not just generate them from the uncode.org spec but added a bunch of stuff. Wine currently builds on OS X with the header order as it stands and figures out someway around it. I guess its using a define in the makefile for _WCHAR_T generated by configure or something. I have not looked so don't quote me on that. I don't really care if you want to change it to make it less of a hassle to build on OS X for ReactOS but its just going to break again next time someone syncs the unicode lib so its better if you can work around it in the makefile. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

18 years

6
15
0 0

Re: [ros-dev] [ros-diffs] [fireball] 28448: - Allow pci read/writes during proving BAR's size operation

by Aleksey Bragin

Hi, sorry - no, this is an olpc-specific code in olpc branch, I have to emulate some PCI hardware (the code is taken from Linux), however ReactOS's PCI access is more complicated, and thus I slightly improved the code. As for that crash - hmm. I will try the real hardware today maybe. WBR, Aleksey Bragin. On Aug 22, 2007, at 7:31 AM, James Tabor wrote: > Hi! > Could this be related to 28448? I mean could it fix this? The > buffer address > goes down from 8XXXXX to 3fffff (yes backwards, I watch it) and > faults. > This fault was before 28448 and on real hardware. Display is normal > and mouse > moves. > Thanks, > James > > Unhandled exception > ExceptionCode: c0000005 > Faulting Address: 3fffff > Address: 78010e04 C:\ReactOS\system32\msvcrt.dll > CS:EIP 1b:78010e04 > DS 23 ES 23 FS 3b GS 0 > EAX: 0010ad41 EBX: 003fffff ECX: 00001000 > EDX: 009a2068 EBP: 0087f5b4 ESI: 00000002 ESP: 0087f5a0 > EDI: 009a2068 EFLAGS: 00010217 > Frames: > 78000000+122c6 C:\ReactOS\system32\msvcrt.dll > 400000+742eb C:\ReactOS\explorer.exe > 400000+609f4 C:\ReactOS\explorer.exe > > _write lib/sdk/crt/io/write.c Line 55 > . > . > . > while (_nbyte--) { > ----> if (*in == 0x0a) { > . > . > . > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

18 years

1
0
0 0

[ros-diffs] [fireball] 28448: - Allow pci read/writes during proving BAR's size operation

by James Tabor

Hi! Could this be related to 28448? I mean could it fix this? The buffer address goes down from 8XXXXX to 3fffff (yes backwards, I watch it) and faults. This fault was before 28448 and on real hardware. Display is normal and mouse moves. Thanks, James Unhandled exception ExceptionCode: c0000005 Faulting Address: 3fffff Address: 78010e04 C:\ReactOS\system32\msvcrt.dll CS:EIP 1b:78010e04 DS 23 ES 23 FS 3b GS 0 EAX: 0010ad41 EBX: 003fffff ECX: 00001000 EDX: 009a2068 EBP: 0087f5b4 ESI: 00000002 ESP: 0087f5a0 EDI: 009a2068 EFLAGS: 00010217 Frames: 78000000+122c6 C:\ReactOS\system32\msvcrt.dll 400000+742eb C:\ReactOS\explorer.exe 400000+609f4 C:\ReactOS\explorer.exe _write lib/sdk/crt/io/write.c Line 55 . . . while (_nbyte--) { ----> if (*in == 0x0a) { . . .

18 years

1
0
0 0

Re: [ros-dev] IoCheckEaBufferValidity

by Aleksey Bragin

Hello, please provide your real name (this is a must for every commit), and also how to test it under Windows (maybe you wrote some test app for this - it would be useful too). WBR, Aleksey Bragin. On Aug 21, 2007, at 3:39 AM, netzimme(a)aim.com wrote: > Hallo > > Have a patch that implemented the function IoCheckEaBufferValidity > in ntoskrnl\io\iomgr\util.c. > Tested with Windows 2000 and Vista Ultimate 64 Bit. > Perhaps some one can comit it for me. > > Thanks > dz >

18 years

2
2
0 0

IoCheckEaBufferValidity

by netzimme＠aim.com

Hallo Have a patch that implemented the function IoCheckEaBufferValidity in ntoskrnl\io\iomgr\util.c. Tested with Windows 2000 and Vista Ultimate 64 Bit. Perhaps some one can comit it for me. Thanks dz ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. =================================================================== --- file.c (revision 28441) +++ file.c (working copy) @@ -1632,6 +1632,7 @@ IN ULONG Options) { KPROCESSOR_MODE AccessMode; + ULONG EaErrorOffset; HANDLE LocalHandle = 0; LARGE_INTEGER SafeAllocationSize; PVOID SystemEaBuffer = NULL; @@ -1732,10 +1733,10 @@ /* Validate the buffer */ Status = IoCheckEaBufferValidity(SystemEaBuffer, EaLength, - NULL); + &EaErrorOffset); if (!NT_SUCCESS(Status)) { - /* FIXME: Fail once function is implemented */ + DPRINT1("FIXME: IoCheckEaBufferValidity failed with Status: %lx\n",Status); } } } Index: util.c =================================================================== --- util.c (revision 28441) +++ util.c (working copy) @@ -129,8 +129,9 @@ return STATUS_SUCCESS; } + /* - * @unimplemented + * @implemented */ NTSTATUS NTAPI @@ -138,10 +139,58 @@ IN ULONG EaLength, OUT PULONG ErrorOffset) { - UNIMPLEMENTED; - return STATUS_NOT_IMPLEMENTED; + PFILE_FULL_EA_INFORMATION EaBufferEnd; + ULONG LenOfEaBuffer; + UINT IntEaLength; + + IntEaLength = EaLength; + EaBufferEnd = EaBuffer; + + while (IntEaLength >= 8) + { + LenOfEaBuffer = EaBufferEnd->EaNameLength+EaBufferEnd->EaValueLength + 9; + if (IntEaLength >= LenOfEaBuffer) + { + if (EaBufferEnd->EaName[EaBufferEnd->EaNameLength]==0) + { + if (EaBufferEnd->NextEntryOffset == 0) + { + IntEaLength = IntEaLength - LenOfEaBuffer; + if (IntEaLength>=0) + { + return STATUS_SUCCESS; + } + } + else + { + LenOfEaBuffer = ((LenOfEaBuffer + 3) & 0xFFFFFFFC); + if (EaBufferEnd->NextEntryOffset == LenOfEaBuffer) + { + if (EaBufferEnd->NextEntryOffset>0) + { + IntEaLength = IntEaLength - EaBufferEnd->NextEntryOffset; + if (IntEaLength>=0) + { + LenOfEaBuffer = EaBufferEnd->NextEntryOffset; + EaBufferEnd = (PFILE_FULL_EA_INFORMATION)((PBYTE)EaBufferEnd + LenOfEaBuffer); + continue; + } + } + } + } + } + } + break; + } + if (ErrorOffset != NULL) + { + *ErrorOffset = (ULONG)((PBYTE)EaBufferEnd - (PBYTE)EaBuffer); + } + + return STATUS_EA_LIST_INCONSISTENT; } + /* * @unimplemented */

18 years

2
2
0 0

Re: [ros-dev] [ros-diffs] [cfinck] 28423: - Always include "wine/unicode.h" before all other headers, when we need the wchar_t type. unicode.h includes windef.h, which includes winnt.h, which has the handling for the wchar_t type. As it's the first included he

by Steven Edwards

On 8/19/07, cfinck(a)svn.reactos.org <cfinck(a)svn.reactos.org> wrote: > - Always include "wine/unicode.h" before all other headers, when we need the wchar_t type. Please stop changing the header order. If you need to do this then something is wrong. The Wine headers are mostly correct as far as the PSDK/WDK goes and if you build Wine on MSVC you DO NOT have to make these invasive changes to the source even when using the SDK headers. Fix the ROS headers or work around system limitations some other way. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

18 years

2
1
0 0

Freedom

by James Tabor

Hi, I want ReactOS to become free again. From gnu.org, Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software: * The freedom to run the program, for any purpose (freedom 0). * The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. * The freedom to redistribute copies so you can help your neighbor (freedom 2). * The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this. We forget what this is all about. We need to be liberated from the shackles and chains. Replace "Tainted Developers" with this: Referring to Proprietary Programs: Don't in any circumstances refer to any closed source proprietary code for or during your work on ReactOS! (Or to any other proprietary programs, Unix, Novel, Solaris, Microsoft,.) If you have a vague recollection of the internals of a closed source program, this does not absolutely mean you can't write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the software version irrelevant and dissimilar to your results. It's from: http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#… If is good for FSF/GNU it's good enough for us. I don't think we need to vote on this, just change it! Remember this is GNU/ReactOS! Not SFLC/Wine! Thanks, James

18 years

3
2
0 0

Remote desktop on ROS

by Gabriel ilardi

Dear Devs, I've tested a win32 port of rdesktop for linux, and it works in current trunk (http://img440.imageshack.us/my.php?image=rdesktop3hi1.jpg), since our rdp client doesn't work, I was wondering if this one could be included instead, it's released under gpl, perhaps adding a gui, I don't think it's a lot of work, correct me if I'm wrong, you can find the sources here: http://os.american-data.com/rdesktop/win32/ Best regards, gabriel_it Have a nice day! _________________________________________________________________ Scarica GRATIS Internet Explorer 7 personalizzato MSN http://optimizedie7.msn.com/default.aspx?mkt=it-it

18 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev