Re: [ros-dev] [ros-diffs] [hbelusca] 68139: [TOOLS] Improve bin2c by saving in a #define the size of the generated array, and specify this size in the declaration of the array so that doing sizeof(...
t; --- trunk/reactos/hal/halx86/legacy/bussupp.c [iso-8859-1] (original)
> +++ trunk/reactos/hal/halx86/legacy/bussupp.c [iso-8859-1] Sun Jun 14
> 18:13:50 2015
> @@ -715,7 +715,7 @@
>
> /* Isolate the class name */
> sprintf(LookupString, "C %02x ", PciData->BaseClass);
> -ClassName = strstr(ClassTable, LookupString);
> +ClassName = strstr((PCHAR)ClassTable, LookupString);
> if (ClassName)
> {
> /* Isolate the subclass name */
> @@ -736,7 +736,7 @@
>
> /* Isolate the vendor name */
> sprintf(LookupString, "\r\n%04x ", PciData->VendorID);
> -VendorName = strstr(VendorTable, LookupString);
> +VendorName = strstr((PCHAR)VendorTable, LookupString);
> if (VendorName)
> {
> /* Copy the vendor name into our buffer */
>
> Modified: trunk/reactos/tools/bin2c.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/tools/bin2c.c?rev=68139&r1=68138&r2=68139&view=diff
>
> ==
> --- trunk/reactos/tools/bin2c.c [iso-8859-1] (original)
> +++ trunk/reactos/tools/bin2c.c [iso-8859-1] Sun Jun 14 18:13:50 2015
> @@ -13,8 +13,8 @@
> FILE* inFile;
> FILE* outCFile;
> FILE* outHFile;
> +size_t bufLen;
> unsigned char ch;
> -unsigned char cnt;
>
> /* Validate the arguments */
> if (argc < 5)
> @@ -46,14 +46,6 @@
> return -1;
> }
>
> -/* Generate the header file and close it */
> -fprintf(outHFile, "/* This file is autogenerated, do not edit.
> */\n\n");
> -fprintf(outHFile, "#ifndef CHAR\n"
> - "#define CHAR char\n"
> - "#endif\n\n");
> -fprintf(outHFile, "extern CHAR %s[];\n", argv[4]);
> -fclose(outHFile);
> -
> /* Generate the source file and close it */
> fprintf(outCFile, "/* This file is autogenerated, do not edit.
> */\n\n");
> if (argc >= 7)
> @@ -69,25 +61,29 @@
> /* Add the array attribute */
> fprintf(outCFile, "%s ", argv[5]);
> }
> -fprintf(outCFile, "CHAR %s[] =\n{", argv[4]);
> +fprintf(outCFile, "unsigned char %s[] =\n{", argv[4]);
>
> -cnt = 0;
> -ch = fgetc(inFile);
> +bufLen = 0;
> +ch = fgetc(inFile);
> while (!feof(inFile))
> {
> -if ((cnt % 16) == 0)
> -{
> +if ((bufLen % 16) == 0)
> fprintf(outCFile, "\n ");
> -cnt = 0;
> -}
> +
> fprintf(outCFile, " 0x%02x,", (unsigned int)ch);
> -++cnt;
> +++bufLen;
> ch = fgetc(inFile);
> }
> /* Put a final NULL terminator */
> -fprintf(outCFile, "\n0x00");
> +fprintf(outCFile, "\n0x00"); ++bufLen;
> fprintf(outCFile, "\n};\n");
> fclose(outCFile);
> +
> +/* Generate the header file and close it */
> +fprintf(outHFile, "/* This file is autogenerated, do not edit.
> */\n\n");
> +fprintf(outHFile, "#define %s_SIZE %Iu\n" , argv[4], bufLen);
> +fprintf(outHFile, "extern unsigned char %s[%Iu];\n", argv[4], bufLen);
> +fclose(outHFile);
>
> /* Close the input file */
> fclose(inFile);
>
>
>
--
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
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] PATCH: Get configure and host-tools building on arm again
--
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
Index: dll/win32/dbghelp/compat.h
===
--- dll/win32/dbghelp/compat.h (revision 68086)
+++ dll/win32/dbghelp/compat.h (working copy)
@@ -256,7 +256,108 @@
DWORD SegSs;
BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
} CONTEXT, *PCONTEXT;
+
+#else /* ARM? */
+
+/* The following flags control the contents of the CONTEXT structure. */
+
+#define CONTEXT_ARM0x020
+#define CONTEXT_CONTROL (CONTEXT_ARM | 0x0001)
+#define CONTEXT_INTEGER (CONTEXT_ARM | 0x0002)
+#define CONTEXT_FLOATING_POINT (CONTEXT_ARM | 0x0004)
+#define CONTEXT_DEBUG_REGISTERS (CONTEXT_ARM | 0x0008)
+
+#define CONTEXT_FULL (CONTEXT_CONTROL | CONTEXT_INTEGER)
+
+#define EXCEPTION_READ_FAULT0
+#define EXCEPTION_WRITE_FAULT 1
+#define EXCEPTION_EXECUTE_FAULT 8
+
+typedef struct _RUNTIME_FUNCTION
+{
+DWORD BeginAddress;
+union {
+DWORD UnwindData;
+struct {
+DWORD Flag : 2;
+DWORD FunctionLength : 11;
+DWORD Ret : 2;
+DWORD H : 1;
+DWORD Reg : 3;
+DWORD R : 1;
+DWORD L : 1;
+DWORD C : 1;
+DWORD StackAdjust : 10;
+} DUMMYSTRUCTNAME;
+} DUMMYUNIONNAME;
+} RUNTIME_FUNCTION, *PRUNTIME_FUNCTION;
+
+#define UNWIND_HISTORY_TABLE_SIZE 12
+typedef struct _UNWIND_HISTORY_TABLE_ENTRY
+{
+DWORD ImageBase;
+PRUNTIME_FUNCTION FunctionEntry;
+} UNWIND_HISTORY_TABLE_ENTRY, *PUNWIND_HISTORY_TABLE_ENTRY;
+
+typedef struct _UNWIND_HISTORY_TABLE
+{
+DWORD Count;
+BYTE LocalHint;
+BYTE GlobalHint;
+BYTE Search;
+BYTE Once;
+DWORD LowAddress;
+DWORD HighAddress;
+UNWIND_HISTORY_TABLE_ENTRY Entry[UNWIND_HISTORY_TABLE_SIZE];
+} UNWIND_HISTORY_TABLE, *PUNWIND_HISTORY_TABLE;
+
+typedef struct _CONTEXT {
+/* The flags values within this flag control the contents of
+ a CONTEXT record.
+
+ If the context record is used as an input parameter, then
+ for each portion of the context record controlled by a flag
+ whose value is set, it is assumed that that portion of the
+ context record contains valid context. If the context record
+ is being used to modify a thread's context, then only that
+ portion of the threads context will be modified.
+
+ If the context record is used as an IN OUT parameter to capture
+ the context of a thread, then only those portions of the thread's
+ context corresponding to set flags will be returned.
+
+ The context record is never used as an OUT only parameter. */
+
+ULONG ContextFlags;
+
+/* This section is specified/returned if the ContextFlags word contains
+ the flag CONTEXT_INTEGER. */
+ULONG R0;
+ULONG R1;
+ULONG R2;
+ULONG R3;
+ULONG R4;
+ULONG R5;
+ULONG R6;
+ULONG R7;
+ULONG R8;
+ULONG R9;
+ULONG R10;
+ULONG Fp;
+ULONG Ip;
+
+/* These are selected by CONTEXT_CONTROL */
+ULONG Sp;
+ULONG Lr;
+ULONG Pc;
+ULONG Cpsr;
+} CONTEXT;
+
+BOOLEAN CDECLRtlAddFunctionTable(RUNTIME_FUNCTION*,DWORD,DWORD);
+BOOLEAN CDECLRtlDeleteFunctionTable(RUNTIME_FUNCTION*);
+PRUNTIME_FUNCTION WINAPI
RtlLookupFunctionEntry(ULONG_PTR,DWORD*,UNWIND_HISTORY_TABLE*);
#endif
+
typedef
EXCEPTION_DISPOSITION
NTAPI
Index: lib/sdk/crt/crt.cmake
===
--- lib/sdk/crt/crt.cmake (revision 68086)
+++ lib/sdk/crt/crt.cmake (working copy)
@@ -505,7 +505,6 @@
math/arm/log.s
math/arm/log10.s
math/arm/pow.s
-math/arm/sqrt.s
math/arm/tan.s
math/arm/_logb.s
math/arm/__dtoi64.s
Index: tools/rsym/CMakeLists.txt
===
--- tools/rsym/CMakeLists.txt (revision 68086)
+++ tools/rsym/CMakeLists.txt (working copy)
@@ -7,6 +7,8 @@
add_executable(rsym rsym.c)
elseif(ARCH STREQUAL "amd64")
add_executable(rsym rsym64.c)
+elseif(ARCH STREQUAL "arm")
+add_executable(rsym rsym64.c)
endif()
target_link_libraries(rsym rsym_common dbghelphost zlibhost unicode)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 63135: Arch, please do not mix up ANSI vs. UNICODE string functions, do you?
On Sun, May 4, 2014 at 3:59 PM, Hermès BÉLUSCA - MAÏTO < hermes.belu...@sfr.fr> wrote: > I know, I'm currently not converting all the cmdutils to UNICODE but yes it > should be done... > Heh by the time that happens, ftp will be the new uucp. talk about 'here be dragons': Added *Tue Jan 4 04:03:57 2005 UTC* (9 years, 4 months ago) by *sedwards* -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] About hotpatchable dlls on ReactOS
Here is a reimplementation for those that don't want to pay the 10k http://www.codeproject.com/Articles/44326/MinHook-The-Minimalistic-x86-x64-API-Hooking-Libra On Fri, Feb 28, 2014 at 7:11 AM, Ged Murphy wrote: > Ahh, the detours trampoline. Hand over £10k to Microsoft and you can have > their source ;) > > > > > > *From:* ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] *On > Behalf Of *Hermès BÉLUSCA - MAÏTO > *Sent:* 28 February 2014 14:29 > *To:* 'ReactOS Development List' > *Subject:* Re: [ros-dev] About hotpatchable dlls on ReactOS > > > > Not exactly. I'm referring to the fact that, starting with Windows XP sp1 > (or 2), and in windows 2k3, usual dlls like kernel32, user32 and others > (and maybe some exes) have, in the prologue of their exported APIs, two > bytes that allows for detouring the API (that allows for in-memory > hotpatch). Maybe that it's used when patching a core dll, when you cannot > modify its file directly without any reboot (otherwise you would need to > reboot for the effects to take change). Here it also appears that some > games and some applications try to patch in-memory some of those Apis, and > if they cannot, they fail. > > > > Searching on wine commits / mailing lists for "hotpatch" and > "DECLSPEC_HOTPATCH" (altough that it's something which doesn't exist in the > PSDK) may give more precision on that subject. > > > > Hermes > > > > *De :* ros-dev-boun...@reactos.org > [mailto:ros-dev-boun...@reactos.org] > *De la part de* Ged Murphy > *Envoyé :* vendredi 28 février 2014 14:55 > *À :* 'ReactOS Development List' > *Objet :* Re: [ros-dev] About hotpatchable dlls on ReactOS > > > > Are you referring to .msp's ? > > > > *From:* ros-dev-boun...@reactos.org > [mailto:ros-dev-boun...@reactos.org] > *On Behalf Of *Hermès BÉLUSCA - MAÏTO > *Sent:* 28 February 2014 13:53 > *To:* ReactOS Development List > *Subject:* [ros-dev] About hotpatchable dlls on ReactOS > > > > Hi guys ! > > > > It seems to appear that some games need standard APIs hotpatchable, in the > sense of MS: few extra bytes present in the prologue of the functions that > allow somebody to detour the API. I knew that this feature was useful for > windows updates, but what I didn't know is that there are other programs > that use it: see this answer from James on the "Epic Win!" forum thread: > http://www.reactos.org/forum/viewtopic.php?f=2&t=10972&p=106823#p106814 , > and the following post is something that I've found about this subject, and > the fact that Wine already have done something about that. > > > > So my question: should we support/create hotpatchable images (of the > standard dlls and maybe ?? exes) in ReactOS ? Is it already done ? If not, > what needs to be added ? It seems that MSVC and GCC handle that a bit > differently. > > > > Cheers, > > Hermès BÉLUSCA - MAÏTO > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Win32 subsystem in 2013
just 1 revision was >>>> spent on such a glorious thing as fixing Wine's bug. >>>> >>>> ReactOS is a just for fun type of project, so I highly appreciate that >>>> efforts were put into all of the above! >>>> However, I still think that it would be beneficial if someone would >>>> put similar efforts into Arwinss to eliminate the need to bring in >>>> hacks and fix stuff which works in Wine for years already, and focus >>>> on developing only those parts which we obviously can't share (GDI, >>>> hardware accelerated graphics, whatever else). >>>> >>>> I lack time to do this myself, but if anyone volunteers I would be >>>> glad to help, share my experience and think up of interesting tasks. >>>> Like, getting Arwinss to work in Windows 2003 instead of its native >>>> subsystem, which would be a nice test. >>>> >>>> Regards, >>>> Aleksey Bragin >>>> >>>> > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.
On Mon, Dec 2, 2013 at 11:36 PM, Sven Barth wrote: > > There is a little problem however: we are talking about the file system > driver which is usually used to install the system. I don't know currently > how Windows manages to update in use boot drivers, but we'd need something > equivalent in place for this. > I don't disagree that it is a challenge. But less than one of trying to win a court case for violating the terms of distribution for someone else's copyright. Who knows, maybe Microsoft will be amicable to give us a special dispensation if we just ask. Stranger things have happened. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.
Copyright law is pretty clear, they can control the terms of distribution of their code and what it can be bundled with. On Mon, Dec 2, 2013 at 1:15 PM, Magnus Olsen wrote: > Hi > About discussions about MS license. the question is if > the license agreement to restrict only to Microsoft Windows is valid in EU. > I do not think so. But only a lawyers can tell about that. Rest of the > world I do not known. > > In sweden lest we got so call negative license agreement. That mean part > of a license agreement is not valid for it is bad for user or goes > against any law. > > > > > 2013/12/2 Steven Edwards > >> Look at how the Core Fonts for the Web are handled. We should have >> generic drivers that are 'good enough' to be able get online and download >> the Microsoft ones if the user wants to take the risk of violating >> Microsofts license. >> >> >> On Mon, Dec 2, 2013 at 9:27 AM, Alex Ionescu wrote: >> >>> These are all legitimate concerns for a FAT driver, but keep in mind the >>> WDK library also has things like large chunks of the storage stack, the >>> input stack, the floppy stack, audio and network stuff, etc... >>> >>> We could decide to keep our current FAT driver (or find a workaround), >>> but still implement this idea for the other drivers. >>> >>> Best regards, >>> Alex Ionescu >>> >>> >>> On Mon, Dec 2, 2013 at 6:37 AM, Michael Fritscher >> > wrote: >>> >>>> Hi, >>>> >>>> normally, I wouldn't have any problem with having drivers on a second >>>> disc >>>> / image. But FAT (and in particular cdfs) are core-drivers in my >>>> opinion, >>>> which are needed almost every time - also for booting from CD for >>>> installation. FAT is widely used still today, e.g. on usb-sticks. >>>> >>>> What are currently the biggest problems in these drivers? If remember >>>> correctly, our cache manager isn't compatible to the one in Windows, and >>>> these drivers have workarounds, is it? >>>> >>>> Perhaps the drivers could be written by a GSoC project or something like >>>> that? >>>> >>>> Additionally, what about NTFS? Is there a ntfs-driver in the >>>> MSDN-library >>>> as is the FAT-driver? If not, almost nothing is won if we use the >>>> fat-driver from MS: The OS- dependent part of the ntfs-driver need to be >>>> written from scratch from us anyway, which could then be reused by our >>>> FAT-driver. And hey, the filesystem part of the FAT-driver shouldn't be >>>> too complicated if we managed to write a NTFS-driver^^ >>>> >>>> Best regards, >>>> Michael Fritscher >>>> >>>> >>>> ___ >>>> Ros-dev mailing list >>>> Ros-dev@reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>> >>> >>> >>> ___ >>> Ros-dev mailing list >>> Ros-dev@reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> >> >> >> -- >> 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 >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ekohl] 61145: [FASTFAT] FsdGetFsVolumeInformation: Return volume creation time.
Look at how the Core Fonts for the Web are handled. We should have generic drivers that are 'good enough' to be able get online and download the Microsoft ones if the user wants to take the risk of violating Microsofts license. On Mon, Dec 2, 2013 at 9:27 AM, Alex Ionescu wrote: > These are all legitimate concerns for a FAT driver, but keep in mind the > WDK library also has things like large chunks of the storage stack, the > input stack, the floppy stack, audio and network stuff, etc... > > We could decide to keep our current FAT driver (or find a workaround), but > still implement this idea for the other drivers. > > Best regards, > Alex Ionescu > > > On Mon, Dec 2, 2013 at 6:37 AM, Michael Fritscher > wrote: > >> Hi, >> >> normally, I wouldn't have any problem with having drivers on a second disc >> / image. But FAT (and in particular cdfs) are core-drivers in my opinion, >> which are needed almost every time - also for booting from CD for >> installation. FAT is widely used still today, e.g. on usb-sticks. >> >> What are currently the biggest problems in these drivers? If remember >> correctly, our cache manager isn't compatible to the one in Windows, and >> these drivers have workarounds, is it? >> >> Perhaps the drivers could be written by a GSoC project or something like >> that? >> >> Additionally, what about NTFS? Is there a ntfs-driver in the MSDN-library >> as is the FAT-driver? If not, almost nothing is won if we use the >> fat-driver from MS: The OS- dependent part of the ntfs-driver need to be >> written from scratch from us anyway, which could then be reused by our >> FAT-driver. And hey, the filesystem part of the FAT-driver shouldn't be >> too complicated if we managed to write a NTFS-driver^^ >> >> Best regards, >> Michael Fritscher >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Roadmap I'm sticking to
On Thu, Apr 8, 2010 at 3:26 PM, Aleksey Bragin wrote: > I already said all that half a year ago. Let's move on to actually making a > usable OS. The debate seems to be what constitutes 'usable'. If Xming could run and be stable for hours+ on end then it could be a usable thin client. I think this would be a good first target. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] fastcall bug
Hi, Have you guys seen this? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41013 Is it really a problem? The discussion came up on wine-devel. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Google summer code
Sorry for the top posting. We don't want nor need access to the sources, everything that is and has been developed is via clean-room reverse engineering. If you can make note of all of the messages you see related to the failures under Wine, that is the best place to start for the Summer of Code. Once there is a good bug report in Winehq, then the Wine developers will be more inclined to see the need of a SoC project. 2010/3/10 Mgr. Janusz Chmiel : > Dear core developers of Reactos, > > I would like to inform YOu about my findings related to screen readers > support while using Wine emulator, because as i understood, Wine and Reactos > are sharing crucial information to make those tools as much Windows > compatible as it is possible. > > 1. NVDA is not able to run in The Wine, which can be downloaded from > PCLINUXOSS repositories, NVDA is only plaing a welcome gong and then i Am > receiving series of error messages, one related to winmm.dll and also other > related to MSAA support. oleacc.dll very probably. > > When i tried one Czech very little screen reader based on using API > hooks and API calls, program is written by using Microsoft Visual Basic 6.0 > professional edition and crucial helper dlls are written in Microsoft visual > C++ but not Express 2005 edition, older release of this programming language > has been used. > > What are mi findings? > > Algorithms used for generating synthesizet speech are working ammazingly in > Wine. but other algorithms for fetching names of buttons, objects and for > getting textual information are not working. > > But i Am afraid, that implementing reliable MSAA support is so much complex > for core developers of Wine or Reactos, that it will never been possible to > reach this goal. > > Many of us are very intelligent and professional developers, who are even > able to use Assembler while compiling and developing Reactos core > components, but i think, that without access to Windows MSAA source code > developing reliable MSAA support will be only big dream, which would never > been come true. > > Reactos is in general very stable and reliable operating system and i > believe, that in future, also many device drivers will work with Reactos. > > If also MSAA support would be added in future, this would be very positive > for many handicapped users, because MSAA is being used not only by screen > readers, but also while using other assistive technology, which are based on > MSAA calls. > > BUt i think, that Microsoft will not want to reveal The MSAA source code, > the modified source code of oleacc.dll, user32.dll and others. Accessing > source code is fortunately possible, but i read about this, that some fee > must be paied to Microsoft to get access to their source code repository, > and i think, that there will be very restricted conditions. > > > _______ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [evb] 45874: - New Framebuffer (Linear) Display Driver
Hi, Thanks for the clarification. I welcome the new driver! On Tue, Mar 9, 2010 at 11:41 PM, Ros Arm wrote: > Hello Steven, > > I have talked with eVb and perhaps there is a language barrier: > > His commit message said that he used the NT4 DDK driver because the license > does not prohibit it (especially as only a fraction of it is used). > > He then said that there have been some small number of changes since NT4, > obviously, and that he used the Virtual Box Display Driver (available under > GPL) to figure out what those changes are. > > Since the Virtual Box Display Driver is actually the 2003 DDK driver, some > people may have wondered why not use it directly, and eVB is explaining that: > > 1) He feels very insecure about Virtual Box/Sun claiming that the code is > truly "GPL" considering the 2003 DDK does not allow that (unless Microsoft > made an exception for Sun -- do note that this code existed before VirtualBox > was under Sun, however). > > 2) There is an additional file, present both in the NT4 DDK version and in > the Virtual Box driver that has a very explicit claim that there is a color > dithering patent that Microsoft will sue you for unless you work at > Microsoft. eVb did not import that file at all in ReactOS, and so we use > standard GDI dithering code. > > eVb finally notes that the previous (ReactOS) driver was actually an obvious > copy of the DDK sample, with variables renamed to hide the truth, but some > comments are long and identical in a way that makes it clear what the > original source of the driver is. Just like VirtualBox/Sun, the developer of > this older ReactOS driver slapped a "GPL 2" license on it, because, it would > seem, renaming variables, is the sure way to be okay with a license. > (Considering the numerous other such abuses throughout the SVN tree, I'm not > surprised). eVb notes that this kind of behavior will land someone in jail > one day. > > So to summarize: > > 1) Old ReactOS driver: pretty much copy/pasted and "fixified" DDK driver to > hide the evidence, slapped with GPL 2 license. > 2) Virtual Box driver: copy/pasted DDK driver slapped with GPL 2 license, > including on top of a very threatening statement from Microsoft about their > color dithering algorithm. > 3) 2003 DDK driver: Cannot be used in open source products under most > licenses, cannot be used for non-Windows products. > 4) NT4 DDK driver: Free to use and re-license as needed (supposedly), but > contains patented code with threatening statement. > ... > 5) eVb's driver: NT4 DDK driver, not relicensed to avoid legal unknown > waters, and without the patented code present. > > For evidence of #1, one can simply compare GetAvailableModes in the current > framebuf driver in screen.c, which is listed as "Copyrighted" by a certain > "Filip Navara", and followed by a GPL 2 license. You can then check > getAvailableModes in screen.c in framebuf_new (with the correct > copyright/license of NT4 DDK). You'll note the code is identical down to the > comments. > > I for one, am thankful that not only is eVb fixing bugs in the graphics > subsystem, but also getting you out of legal trouble. > > -r > >> On Fri, Mar 5, 2010 at 12:29 PM, wrote: >> > - New Framebuffer (Linear) Display Driver to support new unified VGA/VBE >> > miniport. Based on NT4 DDK Sample, with modifications by me (marked with >> > // eVb) to support new functionality needed for 2003-era driver. >> > - Also used Virtual Box Display Driver as sample, which is based on "GPL" >> > Windows 2003 DDK sample driver. Could not use 2003 DDK sample directly >> > because of licensing issues, and feel unsafe about VirtualBox "GPL" driver >> > that says "PATENTED AND ONLY FOR USE IN MICROSOFT PRODUCTS". >> > - Note that old driver was based off DDK sample too, but with variables >> > renamed (some comments identical!) and code reformatted, then marked as >> > "GPL". This is not very good way to share/use code... one day someone can >> > teach you lesson. >> >> I am not sure what this comment is supposed to mean. Are you saying >> that the wishes of the Author should not be respected? The PATENTED >> statement is an extra qualifier. We are talking about two issues, >> patents (which are vague and Copyright which is clear). Clearly the >> author being Microsoft does not want it's code used as a derived work >> for a non-windows OS. As the copyright owner and licensor that is >> their right. Or do you propose that developers ignore the copyright >> law and do
Re: [ros-dev] Summer of Code 2010
On Mon, Mar 8, 2010 at 4:30 PM, Andrew Faulds wrote: > Well, here are some suggestions: Since google likes to reject ReactOS projects, I think it is better to present them as independent projects. > Sound Stack & NVDA (already mentioned) Maybe see if NVDA works under Wine and if not submit it as a project through them, just keep the ReactOS name off of it and everyone is happy except for ReactOS enthusiasts. > USB - Having working USB support, particularly for flash drives would be > very useful I seem to recall someone had developed a USB stack for NT4 for Legacy systems but it was very limited. Perhaps you could submit a project to create a better implementation of this for legacy systems. Are there newer features and functionality in USB that say do not work on Windows 2000? > USB Flash Drive Booting - This is quite important. Having ROS-NVDA bootable > from a flash drive would be useful for the visually impaired etc., as they > could boot any PC into an accessible environment. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [evb] 45873: - Add new unified VGA/VBE miniport driver
On Fri, Mar 5, 2010 at 2:56 PM, Ged Murphy wrote: > As Steven is our IP guy, is it not worth him going over the EULA too? Remember IANAL, just trying to help watch out for the project. I would still like to look over it if its handy though but I recall the nt4 ddk was pretty liberal. The project policy has been a little inconsistent regarding using Microsoft code before, and I was pretty conservative on it but as long as the licensing is clear, we should not fear it from a copyright point of view. I mean hell, they've been submitting patches for Linux for Virtual Machine stuff. We've got more to fear from patents anyway. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [evb] 45873: - Add new unified VGA/VBE miniport driver
On Fri, Mar 5, 2010 at 2:01 PM, Aleksey Bragin wrote: > Yes, I researched this issue when adding them, and yes - thank you, > Microsoft. > > All work of ros.arm is also based exclusively on NT4 DDK (actually, they > don't ship so many video stuff in newer DDKs at all). OK cool, that's good enough for me. I would just hate to see some day down the road some company that wants to sell ReactOS products and services become liable to Microsoft. Thanks for keeping an eye out on this. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [evb] 45873: - Add new unified VGA/VBE miniport driver
On Fri, Mar 5, 2010 at 12:35 PM, Ros Arm wrote: > Stipulation only exist in newer DDK, that why old sample used. > > Also, storage drivers in ReactOS are NT4 (atapi) DDK sample too, so why > raising issue now? I've not looked closely at the storage drivers. If the EULA for the NT4 DDK allows it, then I don't care. Thank you Microsoft. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [evb] 45874: - New Framebuffer (Linear) Display Driver to support new unified VGA/VBE miniport. Based on NT4 DDK Sample, with modifications by me (marked with // eVb) to supp
On Fri, Mar 5, 2010 at 12:29 PM, wrote: > - New Framebuffer (Linear) Display Driver to support new unified VGA/VBE > miniport. Based on NT4 DDK Sample, with modifications by me (marked with // > eVb) to support new functionality needed for 2003-era driver. > - Also used Virtual Box Display Driver as sample, which is based on "GPL" > Windows 2003 DDK sample driver. Could not use 2003 DDK sample directly > because of licensing issues, and feel unsafe about VirtualBox "GPL" driver > that says "PATENTED AND ONLY FOR USE IN MICROSOFT PRODUCTS". > - Note that old driver was based off DDK sample too, but with variables > renamed (some comments identical!) and code reformatted, then marked as > "GPL". This is not very good way to share/use code... one day someone can > teach you lesson. I am not sure what this comment is supposed to mean. Are you saying that the wishes of the Author should not be respected? The PATENTED statement is an extra qualifier. We are talking about two issues, patents (which are vague and Copyright which is clear). Clearly the author being Microsoft does not want it's code used as a derived work for a non-windows OS. As the copyright owner and licensor that is their right. Or do you propose that developers ignore the copyright law and do it anyway? If you want to import the Windows 2003 DDK driver and create a derived work in violation of the terms, do the rest of us a favor and upload a scanned copy of your drivers license, passport or whatever as a resource for this driver so Microsoft will know exactly who to sue. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [evb] 45873: - Add new unified VGA/VBE miniport driver. Based on NT4 DDK Cirrus Miniport Driver Sample with my modifications (marked with // eVb) to change Cirrus parts to VG
Does the EULA allow you to redistribute sample code without stipulations? I seem to recall certain versions of the DDK requiring that derivative works be used only with a Windows OS. Can you please send me a copy of the EULA for the DDK? Thanks Steven On Fri, Mar 5, 2010 at 12:22 PM, wrote: > Author: evb > Date: Fri Mar 5 18:22:18 2010 > New Revision: 45873 > > URL: http://svn.reactos.org/svn/reactos?rev=45873&view=rev > Log: > - Add new unified VGA/VBE miniport driver. Based on NT4 DDK Cirrus Miniport > Driver Sample with my modifications (marked with // eVb) to change Cirrus > parts to VGA parts if needed. Also add VBE suppor which is not in Cirrus > driver, but exists in Windows VGA miniport. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Wine Gecko Installer @ 2nd boot
On Wed, Mar 3, 2010 at 1:38 PM, Andrew Faulds wrote: > I've always wondered why it wasn't included anyway, as not only ROS Explorer > uses it, any app that uses HTML needs it, and these are becoming > increasingly common. It's a artifact of Wine. They make it optional so that you can override the builtin mshtml and friends, install the Windows IE and use it. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 45433: [NTOS] On MSVC implement _lgdt, __sgdt, __lldt, __sldt, __ltr and __str as assembly functions, because there is no inline assembly. The MSVC/ML64 built kern
On Thu, Feb 4, 2010 at 10:05 PM, wrote: > Author: tkreuzer > Date: Fri Feb 5 04:05:51 2010 > New Revision: 45433 > > URL: http://svn.reactos.org/svn/reactos?rev=45433&view=rev > Log: > [NTOS] > On MSVC implement _lgdt, __sgdt, __lldt, __sldt, __ltr and __str as assembly > functions, because there is no inline assembly. > The MSVC/ML64 built kernel now boots and WinDbg connects. And there was much rejoicing ;) -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sir_richard] 45281: [NTOS]: Trunk boots now (interesting that buildbot's QEMU does not support SYSENTER, as newer versions do), so remove the test DPRINTs.
On Wed, Jan 27, 2010 at 11:16 AM, Andrew Faulds wrote: > No, The BuildBot will run off of it's own builds :) Since ReactOS can self-host and has networking, this should be the goal. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
On Tue, Jan 19, 2010 at 6:11 PM, James Tabor wrote: > The same thing with the kernel, we can use Linux instead! Create a > distribution with it and call it Lindows! Oh wait! That ship has set > sail and moved on~! Although Jim likes the hyperbole, he is right. Arwinss is a stop gap solution that should eventually be deprecated except for the X11 module and used as a basis for verifying the 'correct' win32 subsystem. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss presentation
On Tue, Jan 19, 2010 at 3:23 PM, Colin Finck wrote: > Maybe because we already had this one in July: > http://www.reactos.org/pipermail/ros-dev/2009-July/011896.html > > As I'm not a Win32k dev, I shouldn't argue about technical details. But I > still don't believe that all the points expressed in e.g. > http://www.reactos.org/pipermail/ros-dev/2009-July/011933.html are suddenly > invalid, so that we can easily say that Arwinss is "the better > architecture". For me, it looks like the slides want to give this > impression. > > Of course, I also want to see ReactOS going forward and Arwinss can surely > help for now. But simply accepting it as our new official Win32k > architecture I don't think we can make it that easy after all previous > opinions. There is no reason things cannot be developed in parallel. Samba 3 and Samba 4 have been in parallel development for how long now? I mean, we don't want to drive anyone away from ReactOS development, or throw out the work everyone is doing on the current win32k.sys and friends. Why could we not have the best of both worlds. Sure i would add a little bit of extra time to the build time and to build both subsystems. It should be possible to add some infrastructure to allow for the user to pick or switch the subsystem they are using. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sir_richard] 45052: Patch that fixes VMWare boot (and
On Tue, Jan 12, 2010 at 12:50 PM, Jose Catena wrote: > I'm doing that. Right now I compile and run ntoskrnl in msc (vc9). Runs > mostly but I'm still fixing bugs. > I have written new small platform and compiler dependent includes and > eliminate all unnecessary conditionals everywhere else, this cleans up > things a lot. > But, I asked if my first patch was reported correctly and if I should submit > more, received no answer, and it's still not reviewed. I suppose because I > am not a respectful enough noob and didn't start kissing asses. So I'm not > going to submit any more unless this childish attitude is fixed. But I'll > put all my work periodically in my server and announce the availability here > so that anyone interested could download it and use whatever you want in > ReactOS. I think the inverse is true, the more aggressive of an ass you are the more attention your patches receive. I wish I could review your patches for you but am more in to project relations and legal issues than coding but it sounds like you've got the right stuff. Maybe privately talk to Fireball about review and commit access? -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ekohl] 45020: Removed outdated email addresses.
On Sun, Jan 10, 2010 at 3:56 PM, Gregor Schneider wrote: > I guess we could even live without the developer names in the file header. > Just inserting "ReactOS dev team" or similar would save a lot of useless > discussions. Current name listings are normally incomplete anyways and only > a SVN blame can reveal the real authors. For credits and E-Mail contacts > there's a credits file. It is the authors job to insure his name appears in the header if he is contribution enough to a source file to have a copyright claim. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Improving our procedure
On Tue, Dec 15, 2009 at 1:57 PM, Alex Ionescu wrote: > You know what else is boring? Going to a shitty university class, going to > meetings at work, listening to your wife whine about her backstabbing > girlfriends, and helping your child work out a 4th grade math problem. > > It's called responsibility. If we made it a requirement for people just be responsible and write proper Changelog messages as part of the commit then there would not be the added responsibility of doing it after the fact. The release manager could just grep for important shit and be done with it. I am in favor of public ridicule, even those of us that don't code but review patches can help out. Every time some commits a patch with an inconclusive Changelog we should call them to the carpet and if it keeps happening they need commit access revoked. I know of no other major open source project that would put up with the shit. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dreimer] 44603: Using the right Cross Compiler is useful, of course. Now We just need a native one, because the cygwin one has evil *nix, blasphemical, god negating and dev
On Tue, Dec 15, 2009 at 11:07 AM, wrote: > Author: dreimer > Date: Tue Dec 15 17:07:47 2009 > New Revision: 44603 > > URL: http://svn.reactos.org/svn/reactos?rev=44603&view=rev > Log: > Using the right Cross Compiler is useful, of course. Now We just need a > native one, because the cygwin one has evil *nix, blasphemical, god negating > and devil worshipping search paths. Don't hold back. Tell us how you really feel. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 44558: added Wine on ReactOS - Inkscape.svg added Wine on ReactOS.svg My "Wine on ReactOS" diagram, in SVG format, two variants (Inkscape-friendly and optimized f
On Sat, Dec 12, 2009 at 8:40 PM, wrote: > Author: hyperion > Date: Sun Dec 13 02:40:56 2009 > New Revision: 44558 > > URL: http://svn.reactos.org/svn/reactos?rev=44558&view=rev > Log: > added Wine on ReactOS - Inkscape.svg > added Wine on ReactOS.svg > My "Wine on ReactOS" diagram, in SVG format, two variants > (Inkscape-friendly and optimized for the web) > > added COPYING > Licensing information on the images > > Added: > trunk/press-media/art/COPYING > trunk/press-media/art/Wine on ReactOS - Inkscape.svg > trunk/press-media/art/Wine on ReactOS.svg Maybe there should be translucent wine bottles over user32/gdi32/kernel32/etc where we use snippets and whole source files. I do like this image though! I will use it the next time I give a presentation. Thanks! -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)
On Thu, Nov 12, 2009 at 8:32 PM, Steven Edwards wrote: > On Thu, Nov 12, 2009 at 8:29 PM, Steven Edwards wrote: >> On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu wrote: >>> 1) You would get the SAME ADVANTAGE by having the FILE on another >>> physical drive! >> >> Wouldn't you still have a problem with fragmentation leading to >> additional io? I ask because the VMware/Netapp best practices for >> Windows and Linux on ESX clusters still recommends a separate >> filesystem dedicated to swap regardless of the the underlying backend >> be it block (iSCSI, Fiberchannel) or file (NFS). This kind of >> surprises me because you would think that if your using shared storage >> such a NetAPP Filer the IO is spread across all drives anyway so you >> save mostly nothing on IO so the only thing I can think is that a >> separate filesystem saves a small amount due to consolidation of all >> fragments to one location. > > Sorry if the point of the question is not clear. In a RAID/NAS/SAN > backend situation, ALL DRIVES are in effect the same PHYSICAL DRIVE so > that's why I ask why one would still be recommended to have a separate > filesystem. Ping? Nobody? So no idea why a separate dedicate virtual drive is recommended for the pagefile.sys? Like I said, using shared storage as a backend be it raided volume, iscsi, fiberchannel or nfs is in effect the same thing as having one physical drive since all IO ops are effectively distributed evenly across all drives, making the volume akin to one physical drive. If there really is no benefit then they are wrong and having the swap file on any volume really is fine. Maybe VMware and NetApp are wrong and just have subscribed to group think. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)
On Thu, Nov 12, 2009 at 8:29 PM, Steven Edwards wrote: > On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu wrote: >> 1) You would get the SAME ADVANTAGE by having the FILE on another >> physical drive! > > Wouldn't you still have a problem with fragmentation leading to > additional io? I ask because the VMware/Netapp best practices for > Windows and Linux on ESX clusters still recommends a separate > filesystem dedicated to swap regardless of the the underlying backend > be it block (iSCSI, Fiberchannel) or file (NFS). This kind of > surprises me because you would think that if your using shared storage > such a NetAPP Filer the IO is spread across all drives anyway so you > save mostly nothing on IO so the only thing I can think is that a > separate filesystem saves a small amount due to consolidation of all > fragments to one location. Sorry if the point of the question is not clear. In a RAID/NAS/SAN backend situation, ALL DRIVES are in effect the same PHYSICAL DRIVE so that's why I ask why one would still be recommended to have a separate filesystem. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)
On Thu, Nov 12, 2009 at 11:46 AM, Alex Ionescu wrote: > 1) You would get the SAME ADVANTAGE by having the FILE on another > physical drive! Wouldn't you still have a problem with fragmentation leading to additional io? I ask because the VMware/Netapp best practices for Windows and Linux on ESX clusters still recommends a separate filesystem dedicated to swap regardless of the the underlying backend be it block (iSCSI, Fiberchannel) or file (NFS). This kind of surprises me because you would think that if your using shared storage such a NetAPP Filer the IO is spread across all drives anyway so you save mostly nothing on IO so the only thing I can think is that a separate filesystem saves a small amount due to consolidation of all fragments to one location. ...dont even get me started on other trouble I've had with filesystems and block alignment ;) -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation
> On Tue, Oct 27, 2009 at 9:32 AM, KJK::Hyperion wrote: >> Alex Ionescu wrote: >>> I bet Hitler would've said the same at Nuremberg >> >> he wouldn't have, unlike us he had written a specification beforehand Just to increase the noise ratio slightly more, I came across t and immediately thought of you two. I've not yet decided who is which character ;) http://www.youtube.com/watch?v=DIaQKnzQzj4 -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : [ros-diffs] [sginsberg] 43789: - Replace broken implementation of HalpCalibrateStallExecution with a new implementation by a mysterious HAL ninja and myself. The old implementation
On Tue, Oct 27, 2009 at 9:32 AM, KJK::Hyperion wrote: > Alex Ionescu wrote: >> I bet Hitler would've said the same at Nuremberg > > he wouldn't have, unlike us he had written a specification beforehand Too funny. I love the Mein Kampf as an example of how to do a proper system design specification ;) -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jimtabor] 43782: - Fix wine class test with a sync with wine edit.c.
On Mon, Oct 26, 2009 at 3:30 PM, Ged Murphy wrote: > This looks weird, anyone know what's going on? > +#ifdef _WIN64 > sizeof(EDITSTATE *), /* extra */ > +#else > + sizeof(EDITSTATE *) + sizeof(WORD), /* extra */ > +#endif The Wine sources actually have something along the lines of sizeof some win16 value since the edit control handles all three cases for them. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 43713: - Update arwinss to Wine-1.1.32. - 16 bit code is well isolated by Wine team now, so amount of differences is substantially smaller. Also more compatibility
On Sat, Oct 24, 2009 at 9:20 AM, wrote: > Author: fireball > Date: Sat Oct 24 15:20:16 2009 > New Revision: 43713 > > URL: http://svn.reactos.org/svn/reactos?rev=43713&view=rev > Log: > - Update arwinss to Wine-1.1.32. > - 16 bit code is well isolated by Wine team now, so amount of differences is > substantially smaller. Also more compatibility due to rewritten > user32/resource.c. I was wondering when Alexandre committed this if the new implementation of TranslateAccelerator magic could replace our implementation in trunk? It would be nice to not have multiple implementations of the same functionality floating around. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 43438: [rtl] - Fix an out-of-bounds read in RtlpDidUnicodeToOemWorked. See issue #4888 for more details.
On Tue, Oct 13, 2009 at 2:01 PM, wrote: > - Fix an out-of-bounds read in RtlpDidUnicodeToOemWorked. This has got to be the worst naming I have ever seen for a function. It makes my internal grammar parser want to puke chunks of conjugation and tense. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sginsberg] 43236: - Goodbye __USE_W32API
On Wed, Sep 30, 2009 at 9:32 AM, wrote: > URL: http://svn.reactos.org/svn/reactos?rev=43236&view=rev > Log: > - Goodbye __USE_W32API This is a historic day in ReactOS that unfortunately no one will really remember. Let us celebrate while we can and have much rejoicing! Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Wineconf 2009
On Wed, Sep 23, 2009 at 12:40 PM, KJK::Hyperion wrote: > Daniel Reimer wrote: >> I dont know our recent financial situation, but maybe we can partially >> finance the Devs Costs to get and stay there over the donations. > > The Italian treasury of the ReactOS project currently holds the > vertiginous sum of €8.50 in donations I am not going to be able to make it due to scheduling conflicts but have been in discussion with Fireball about his ability to attend. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sginsberg] 42920: - Get rid of TAG() from the kernel - mmtypes.h: Goodbye TAG(), you won't be missed
On Mon, Aug 24, 2009 at 2:19 PM, wrote: > Author: sginsberg > Date: Mon Aug 24 20:19:53 2009 > New Revision: 42920 > > URL: http://svn.reactos.org/svn/reactos?rev=42920&view=rev > Log: > - Get rid of TAG() from the kernel > - mmtypes.h: Goodbye TAG(), you won't be missed Maybe this has already been done but if not, we should look in to making a janitorial project for it, Alex and I talked years ago about trying to maintain a list with all of the tags that were in use and apply some consistency to the names. I think there is a list somewhere on MSDN that shows all the tag's used in Windows, and we should try to check ours to make sure they match up. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sginsberg] 42920: - Get rid of TAG() from the kernel - mmtypes.h: Goodbye TAG(), you won't be missed
On Tue, Aug 25, 2009 at 10:03 AM, Steven Edwards wrote: > Maybe this has already been done but if not, we should look in to > making a janitorial project for it, Alex and I talked years ago about > trying to maintain a list with all of the tags that were in use and > apply some consistency to the names. Heh, I guess if I looked closer at the commit I would have seen trunk/reactos/ntoskrnl/include/internal/tag.h is pretty close enough. So ignore that noise, but I am wondering if anyone has compared our tags to the Windows names. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 42833: - Implement windows moving (with contents).
On Fri, Aug 21, 2009 at 3:13 PM, wrote: > Author: fireball > Date: Fri Aug 21 21:13:00 2009 > New Revision: 42833 > > URL: http://svn.reactos.org/svn/reactos?rev=42833&view=rev > Log: > - Implement windows moving (with contents). This is one of the Greatest. Commits. Ever. I wish that we could make Office 2007 run just by removing half the commented out code. ;) -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Some upcoming changes
On Mon, Aug 17, 2009 at 6:09 PM, Alex Ionescu wrote: > How about archiving the older logs in a format that may be a one-time > CPU expense, but never have to worry about uncompressing? Ie: I don't > want really old logs accessible through the UI, but just available by > developer request. I think keeping this data around is a good idea. Besides the technical reference reasons a given developer might have, I think there is a good case that can be made via the evolution of conformance in a legal sense. Let's say vendor comes along and says 'this code is stolen, reversed, whatever', we've not only got the code in revision history but we've got a clear example of how 'original' and non-compliant large parts of the system were and how the evolved. Its kind of like saying 'if there is tainted code somewhere, then why the hell is the system not perfect by now'. We would be able to point to another source of history showing its evolution to perfection. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 42530: modified base/setup/vmwinst/vmwinst.c modified base/setup/vmwinst/vmwinst.rbuild Implement VMWare detection for Visual C++ as well For cleaner code, use SEH
On Sat, Aug 8, 2009 at 5:38 PM, Alex Ionescu wrote: > Awe, Thomas's "Fuck Alex" code is gone... I think we should add it back with this discussion in comments so posterity is left to ponder. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [gschneider] 42402: asctime/ctime: Check for too low input time, fixes one msvcrt time winetest
On Tue, Aug 4, 2009 at 10:52 PM, Alexander Potashev wrote: > First of all, are you sure that this code is mature enough to care > about minor details? I would say, "@implemented" has been added by > mistake. The whole @implemented/@unimplemented thing is a mistake. It's really a worthless measure to go by. I mean lets say function foo takes 20 args but only 10 are useful most of the time and then 8 out of those are implemented, what do you say? @sorta-buggy-implemented... I think if we are going to have something like this then we need autogenerated implementation details on top of the normal API documentation that we have. My thought is to have something based on the conformance tests results. /* * ShellExecuteEx * * Foo Blah Stuff and Things Docu Blah Blah * * PARAMS *Foo gives stuff * * Returns * Bar returns stuff * * Implementation Status * * %72 implemented * %10 implementation Fuzz (or failure or something, can't think of the best term) * %18 TODO */ Some one want to write a bot that does this during release time? I'd love to be able to hack on it but like all my ideas, I lack the free time. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 42388: - Add "ReactOS Application Manager". This program is replacement "Download !" and appwiz.cpl.
On Tue, Aug 4, 2009 at 3:11 PM, Zachary Gorden wrote: > http://opendn.org/rapps.jpg That is very pretty. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 42388: - Add "ReactOS Application Manager". This program is replacement "Download !" and appwiz.cpl.
On Tue, Aug 4, 2009 at 3:02 PM, wrote: > Author: dchapyshev > Date: Tue Aug 4 21:02:56 2009 > New Revision: 42388 > > URL: http://svn.reactos.org/svn/reactos?rev=42388&view=rev > Log: > - Add "ReactOS Application Manager". This program is replacement "Download !" > and appwiz.cpl. > I don't have the time to do a build at the moment, are there screenshots of this guy anywhere? Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 42333: - Handle case when RosGdiSetDeviceClipping is being called without rects at all (with a respective DPRINT1). - Use combined clipping object everywhere to en
On Sun, Aug 2, 2009 at 6:32 AM, wrote: > - Use combined clipping object everywhere to ensure drawing happens only in > allowed rectangle, see arwinss nr. 15. As a side effect, it fixes FireFox and > other apps which would corrupt memory if trying to blit to area outside of DC. I keep seeing these comments, 'see arwinss nr. #'. Where do I go to look this up? Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] FullFAT replacement for Fastfat.sys
On Thu, Jul 30, 2009 at 10:53 AM, James Walmsley wrote: > Actually thats just being developed into FullFAT already in > preparation for the 1.0.0 release. I believe I already mentioned it, > but here's a link the the linux kernel mailing list that explains how > the patch works and why its legally valid. > > http://lkml.org/lkml/2009/6/26/314 -- A legal discussion about the patch. > http://lkml.org/lkml/2009/6/26/313 -- Technical details of what the patch > does. > > FAT stores a checksum in LFNs of the shortname, this can be used to > verify the integrity of LFN entries in a directory. Of course using > the linux patch, the short name can be used for other puposes. However > its not really journaling because you still have to scan all the > directories. This takes a long time. Right. The set of patches I am thinking of is actually older than Tridge's recent patent avoidance work. But I think the concept was the same. If there is a performance hit then it would not worth it. > Sarocet also makes a good point about the problem with a ReactOS > journaling file. The journal should store some kind of hash or > checksum value of the state of the FAT table (which is probably too > big). Or atleast the directories affected by the journal changes. If > this hash differs before journal transactions are committed to the FS > then the journal should clear that transaction and not commit it. > > Really journaling should only be enabled for a ReactOS system > partition, using journaling on removable media wouldn't bring any > great benefit, because of the effect that Sarocet described. > > Still I think the journaling is something we won't add until the > driver is working and stable. I agree. It would be nice to have but that is way down the road but for now, it would just be nice to have a bullet proof fat32 implementation although I suspect a lot of our problems are deeper than the driver itself. If I recall there has been quite a bit of work in the past to get our vfat driver to function on Windows. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] FullFAT replacement for Fastfat.sys
2009/7/30 Timo Kreuzer : > What about long file names? Can't we use something like that to work around > the patent? Speaking of the LongFile Name patent and Journaling, there was if I recall, a Linux kernel hacker a while back that addressed both with an interesting patch. If I recall correctly, rather than storing a LFN and a SFN it would only store one or the other and then use the other record as some sort of a checksum on the file in question to achieve a similar effect as a journal record. Maybe its more analogous to UFS soft updates but I think you might get the idea. I'm not all that up on filesystem semantics but I think a bit of googling might turn up what I am talking about. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] FullFAT replacement for Fastfat.sys
On Wed, Jul 29, 2009 at 5:00 PM, Alex Ionescu wrote: > I'm still at a loss as to why you are all ignoring the free, open source, > FastFAT driver in the Microsoft WDK. Speaking just for myself, its not clear to me what in the aggregate of the WDK is actually 'free' and which is just there for reference purposes. I mean it could be perfectly fine and dandy for us to use it, but without the ablity to do proper due diligence, it does not seem to be worth it. Given the history of the fat patent mess, this should seem perfectly clear. Until Microsoft has the desire to clearly lay out for us what is safe to use in an open source project and what is not, I don't see why its worth the risk. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss architecture
On Wed, Jul 29, 2009 at 3:09 PM, Zachary Gorden wrote: > Why would we need the X server for remote access if we have terminal > services? We don't have terminal services though. I mean we should of course, and I should also have a pony. I'm not saying it should go in trunk or not, just pointing out that its kind of a neat feature that has many uses. And besides, if you've ever tried to do rootless RDP to a Linux or Mac host, you would know it makes kittens cry... -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
On Tue, Jul 21, 2009 at 11:59 AM, KJK::Hyperion wrote: > King InuYasha wrote: >> Ok, a little more confused now. You said that the idea that Wine code is >> better than ReactOS code needs to die, but you turn around and basically >> state that Wine code IS better than ReactOS code. Did you mean that the >> idea that ReactOS code is better than Wine code? > > I did There are many different views on 'better' There can be: a is a more technically correct design than b b is more compatible than a b is easier to read than a a is written lang $foo while b is written in lang $bar I am sure we could go on... Needless to say I don't believe using wineserver in win32k is more 'correct' for ReactOS's goals. If our goal is to be fully compatible with Windows its a (general relatively) short term short solution to the end user problems but not to the overall design goal. The correct thing it would seem is IF and this is a big IF, it does prove to function better than our existing win32k/user32/gdi32 then to use it and quickly move one piece of our existing win32k.sys and friends back in at a time to isolate and fix problems while keeping the same level of compatibly and not allowing regressions in wine tests and applications. Also it would be nice to carry forward the new feature we gain which is the remote X display support. If it gets more people to use ReactOS and brings in more users and developers there is a case for being pragmatic. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
On Mon, Jul 20, 2009 at 10:09 AM, Steven Edwards wrote: > Such a library already exists. Google for libX11. It is used for the > rxvt port in Mingw and Cygwin. It simply maps the X11 api to mostly > equivalent Win32 calls. In the ancient past I built a gtk that linked > to it. Sorry I mean't libW11 -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
On Mon, Jul 20, 2009 at 9:31 AM, King InuYasha wrote: > Would it also mean that an X11 API library could be plugged in so that X > based applications can be more easily ported to Windows/ReactOS while still > providing the transparency to view on another machine through X11 protocol? Such a library already exists. Google for libX11. It is used for the rxvt port in Mingw and Cygwin. It simply maps the X11 api to mostly equivalent Win32 calls. In the ancient past I built a gtk that linked to it. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Arwinss
2009/7/20 Javier Agustìn Fernàndez Arroyo : > "support of remote sessions via X Windows" > what the > Does it mean some GUI Linux apps would be able to run into ROS with that new > Win32 subsystem?? No. It means that if we get things like Microsoft Office working under ReactOS then it will be able to seamlessly display to any client running a X server. Linux, Solaris, Mac OS X, Windows with Xming, etc. The immediate commercial applications should be apparent. Combine ReactOS with a Hypervisor subsystem such as Xen and KVM and you have the makings of a true Windows subsystem. Think VMware Fusion or Parallels Coherency but with remote DISPLAY support, etc. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 42000: - Create a branch for upcoming work. " people will eat you alive anyway so it doesn't really matter"
On Sat, Jul 18, 2009 at 3:47 PM, Alex Ionescu wrote: > This is such an awesome russian response :) > "Let me finish the political upheveal first, "restructure" the parliament, > rebuild the economy and then my vision will become clear". What Fireball does in his own oblast will not effect the stability of the empire ;) -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 42000: - Create a branch for upcoming work. " people will eat you alive anyway so it doesn't really matter"
On Fri, Jul 17, 2009 at 8:49 AM, wrote: > Author: fireball > Date: Fri Jul 17 14:49:16 2009 > New Revision: 42000 > > URL: http://svn.reactos.org/svn/reactos?rev=42000&view=rev > Log: > - Create a branch for upcoming work. > > " people will eat you alive anyway so it doesn't really matter" And your going to make children cry when people see what your doing... -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 41755: - Fixes return valuesfor PeekMessageA/W
On Sat, Jul 4, 2009 at 7:51 PM, Colin Finck wrote: > Ehhhm, you probably mean something like 'if ((int)Res == -1 || !Res)', don't > you? The one you've written makes no sense for me. > Maybe that could even be replaced with a simple 'if ((int)Res < 0)', haven't > looked at the whole code yet. Yeah thats it. The number coming first just does not look good to me but like I said its just a matter of style as I browse the commit messages. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 41755: - Fixes return values for PeekMessageA/W
On Fri, Jul 3, 2009 at 5:53 AM, wrote:
> - if (-1 == (int) Res || ! Res)
> - {
> - return Res;
> + if (-1 == (int) Res || !Res)
> + {
> + return FALSE;
I know you didn't write the check and were just changing the return
values but as a matter of style could we do something like
if (((int) Res || !Res) == -1)
or would the extra parens mess up the order of operations? Not a big
deal, its just easier on my eyes.
Thanks
--
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
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tkreuzer] 41604: Rewrite (NtUser)SystemParametersInfo and related. - Instead of getting the data from the window station and other strange places, the values are now mostly
On Wed, Jun 24, 2009 at 10:43 PM, wrote: > - user32_winetest sysparams: before: 634 executed / 235 failures, after: > 1093 executed, 11 failures > Very impressive. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 41424: - Add Symbol font from Wine
On Tue, Jun 16, 2009 at 11:41 AM, wrote: > Author: dchapyshev > Date: Tue Jun 16 19:41:29 2009 > New Revision: 41424 > > URL: http://svn.reactos.org/svn/reactos?rev=41424&view=rev > Log: > - Add Symbol font from Wine Thank you. This will save us a LOT of trouble later with Office applications. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 41344: Fix no-op code for UNIX hosts
On Sun, Jun 7, 2009 at 8:30 PM, KJK::Hyperion wrote: > I don't plan to. If it's good enough for the rest of rbuild, it's good > enough for the new source file Heh ok I didn;t know rbuild abused it anywhere else. Its really just a manner of style anyway. I'll try to fix it if I remember. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 41343: modified tools/rbuild/backend/mingw/mingw.cpp modified tools/rbuild/backend/mingw/mingw.h From now on, the MinGW back-end will also support the Microsoft co
On Sun, Jun 7, 2009 at 7:33 PM, wrote:
> +#include "../../pch.h"
Ditto for here.
> +
> +// TODO? attempt to support Microsoft tools on non-Windows?
> +#if !defined(WIN32)
> +
> +bool
> +MingwBackend::DetectMicrosoftCompiler ( std::string& )
> +{
> + return false;
> +}
There are some crazy people that run cl under Wine. I know older
versions such as the vctoolkit worked. I'm not sure about more recent
revs. I'm happy to try to make time to look in to this at some point.
It would be nice for us Linux and OS X users to be able to verify
things from time to time with msvc without needing a fullblown vm.
Thanks
--
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
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 41344: Fix no-op code for UNIX hosts
On Sun, Jun 7, 2009 at 7:39 PM, wrote: > +#include "../../pch.h" This is really minor but can you fix it by changing the -I path? Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Wineconf 2009
Hi, I just wanted to let everyone know that Wineconf 2009 is going to be held in Holland on Nov 6-8th. I am of course planning on attending and Fireball said that he might as well. If any ReactOS developers are interested in going and don't have the resources, speak up and perhaps some of the users and advocates that follow ReactOS development would be willing to contribute $5 or $10 to the Foundation on your behalf. Information (what little there is currently) is here: http://wiki.winehq.org/WineConf2009 The ReactOS foundation Donation page is here http://www.reactos.org/en/foundation_donate.html Also while there has been some heated exchanges with Wine and ReactOS developers in the past, we do get quite a lot in terms of code from them so if your interested in helping them out, you can donate to the Wine Development Fund, which will help pay for Wine developers to attend. The donation link is on the main page of Winehq.org Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Network source code
On Fri, May 22, 2009 at 5:45 PM, Timo Kreuzer wrote: > I found a bunch of open source network stuff for Windows, that might be > interesting, or maybe not, don't know. Just wanted to share the links... I would not trust any source on pudn.com as being clean. There is tons and tons of postings there containing windows source code. It's easy to get confused about what is legit and what is not but its best just to avoid that site all together. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sedwards] 40919: imported the MT snapshot of the GPL tftp-server for win32 from sourceforge. Minor changes such as formatting and renaming the files, totally untested except
2009/5/14 Timo Kreuzer : > Do we really need this in trunk? Sure, we can say "hey windows has it...", > but shouldn't we actually keep stuff in trunk that is necessary for a basic > core system? I'd rather import Samba TNG into trunk, as it's very much more > what normal users would expect from a Windows like OS than some ftp or > telnet server. I would rather import the VBox drivers into trunk, but I > don't even think of importing it into rosapps. I'd rather import MPC. > Please! Let's focus on stuff that is important for the core instead of > adding more and more 3rd party stuff. The people that download and use > reactos are either people that give a shit about ftp servers or people that > are experienced enough to install them theirselves. IMO it shouldn't even be > in rosapps, but if it was there I could live with it, trunk: bad idea. > We are not Unix/Linux! You want server stuff? Great! Let's make the XAMPP > work properly and get good uptimes. Anything else is wasted space and time. I don't mind moving the stuff out to rosapps but I thought we were going to adopt a targeted makefile system rather than a multi-tree system. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sedwards] 40919: imported the MT snapshot of the GPL tftp-server for win32 from sourceforge. Minor changes such as formatting and renaming the files, totally untested except
On Thu, May 14, 2009 at 2:52 PM, KJK::Hyperion wrote: > Ged wrote: >> Another unix like addition? >> Do we really need this and the previous telnet server in our source? > > to be fair, Windows does provide a command line TFTP client/server. So > far, I've only seen it used for malware spreading, but it's there and we > should provide one too Where I work we use dhcpd/tftp and PXEboot on both Linux and Windows to do automagical deployment services. The end goal with all of this is a ReactOS deployment system from a single image that can provision ReactOS thinkclients/diskless workstations without the need of a Linux or Windows host. Pushing out a freeldr or grub+freeldr or even pxelinux+grub+freeldr image with a blob containing a ROS ramdisk should be pretty simple using isc-dhcpd/tftp on Linux but I'm more interested in the infrastructure side of things right now. Currently the dhcpd with PXE support is the only part we are really missing. We COULD do it from Linux or Windows right now, but I want to get all the infrastructure in place where we don't need any other OS. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 40541: This is why we can't have nice things. Reverting r40536, r40537, due to RosBE differences between Windows and Linux hosts (because RosBE sucks)
On Thu, Apr 16, 2009 at 11:29 AM, KJK::Hyperion wrote: > Tell me about fairness. Or hard work I'm not knocking on what your trying to do, I totally agree with it and everything you stand for ;) I am just curious what the problems are as I build on Linux and OS X and would like to help if possible. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hyperion] 40541: This is why we can't have nice things. Reverting r40536, r40537, due to RosBE differences between Windows and Linux hosts (because RosBE sucks)
On Thu, Apr 16, 2009 at 12:57 AM, wrote: > Author: hyperion > Date: Thu Apr 16 08:57:28 2009 > New Revision: 40541 > > URL: http://svn.reactos.org/svn/reactos?rev=40541&view=rev > Log: > This is why we can't have nice things. Reverting r40536, r40537, due to RosBE > differences between Windows and Linux hosts (because RosBE sucks) I don't think this is fair to the guys that have put a lot of hard work in to RosBE. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sedwards] 40485: add telnet service, enable it by default
On Wed, Apr 15, 2009 at 5:57 AM, Ged wrote: > Have you not got your unix head on here? > I don't think most windows users even know what a telnet server is for, let > along help to stress/develop it. My hope was that it would help us nail down some of the issues we will face when we implement or support a proper ssh server. Eventually I plan on setting telnetd to disabled but given we have no other real security and anyone using ReactOS on any system with any sort of critical data is insane I don't see a problem with it. I would in fact be impressed if someone did manage to make a botnet out of a bunch of ReactOS boxen. The PR would do us some good. > Maybe I'm out of touch here though, if this is indeed useful then I succumb. It will be more useful when I fix the remaining console issues so apps like ctm, tlist, edit, etc work. Stuff like ping, ipconfig, load, route, etc work. Right now calling Get/SetConsoleMode bombs because it is parentless and most complex applications expecting to run in cmd.exe expect to have some sort of real console to set modes. I think I've found a solution I just need to run it by KJK or get the time to test it out. 'There is another...' so to speak. I didn't find it until after I had already started spending a good bit of time working on the current telnetd implementation. http://www.kpym.com/2/kpym/index.htm Its FOSS and does sshd and telnetd and does not seem to suffer from the console problems we face, however there seems to be some sort of problem starting or installing the service the last time I tested. I'd be happy to just dump the current telnetd in favor of it if it can be made to work under ROS. I just don't want to see what limited remote access we have now regress which is why i went ahead and enabled it. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sedwards] 40485: add telnet service, enable it by default
On Tue, Apr 14, 2009 at 2:14 PM, Ged wrote: > Because we recently had a discussion about trying to keep non-essential > things out of trunk in an effort to keep the build time down. Sure I agree with keeping down the build time but I thought we were going to implement a subset of build targets so the apps that make up the main distro would still be in the reactos checkout. If there is consensus that telnetd should be disabled or set to manual then I'll turn it off. Otherwise my plan was to leave it on until we reach 0.4 in the hopes that people would stress it out and help me develop it. Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sedwards] 40485: add telnet service, enable it by default
On Tue, Apr 14, 2009 at 11:05 AM, Ged wrote: > In my opinion, this shouldn’t even be in trunk it should be in rosapps. Why not? Its a default part of Windows Server. As for leaving it disabled by default, in a normal production world I would agree but anyone running ReactOS in any sort of critical environment in its current state should be forever banned from touching a computer. If your really paranoid about it though then this is a good excuse for me to start working on adding authentication to it. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Re : Year 2038 problem
On Sat, Apr 11, 2009 at 11:13 PM, King InuYasha wrote: > Then what DOES NT use to calculate time? Win32 uses SYSTEMTIME and FILETIME structures to store and calculate the time/date which if I recall correctly user a large int to store and calculate time since 1970. No problem with space there. See http://msdn.microsoft.com/en-us/library/ms725473(VS.85).aspx I am curious if the posix subsystem has any problems with the 2038 bug. Most likely not as it should use the correct native functions internally. Any POSIX application that expects normal 32bit time_t under Services for Unix or Subsystem of Unix applications would still be affected. Again, your talking about 1/2 of .0001% of all applications running on Windows though. Maybe a few other applications that have been ported over using a third party static libc doing its own timekeeping would also be affected but like Alex and Ged have pointed out, its a Unix problem. Yes they do exist, Unix, Linux and friends are not perfect. I wonder what Apple's 2038 plans are. Most likely to kill support for 32bit long before ;) -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Downloader tool
On Fri, Apr 10, 2009 at 8:08 PM, Cameron Gutman wrote: > +4 +5 ;) -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [fireball] 40428: - Recognize up to 4 partitions inside every primary partition table. However, installation will be performed to the first partition anyway.
On Thu, Apr 9, 2009 at 8:42 AM, wrote: > Author: fireball > Date: Thu Apr 9 16:42:09 2009 > New Revision: 40428 > > URL: http://svn.reactos.org/svn/reactos?rev=40428&view=rev > Log: > - Recognize up to 4 partitions inside every primary partition table. However, > installation will be performed to the first partition anyway. How is this going to work for GPT disks? I am not quite sure about how the bootcamp emulation does its magic. Logically it seems to me the BSD slice would seem to be the first partition and bootcamp would show up as partition 2. Are we not going to be able to do this? Thanks -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Brainstorming about testing team, roadmap and ReactOS usability
On Wed, Apr 8, 2009 at 3:32 PM, Ged wrote: > If netbooks continue to make an impact, and the ARM processor starts to move > into this territory, I think this is one area we could flourish I agree with this too. Given our smaller footprint than Windows I could see this being a strong point for us. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Brainstorming about testing team, roadmap and ReactOS usability
On Wed, Apr 8, 2009 at 6:06 AM, Aleksey Bragin wrote: > Background information: In the past and nowadays work in ReactOS is > getting done "as it flows". E.g. if we get developers, who wanted to > implement sound support, would do it, and we advertise this in a > release. Or, like Evgeniy Boltik who shows a nice cooperation with > Timo, Jim and Ged on fixing various nasty palette and drawing issues > which were not touched for a few years, often fixing errors > introduced in revisions like 1000 or 4000. > There is no central plan, just a very rough roadmap, mainly > relatively short-term. Everyone is doing a great job nailing down these issues! > This involves, first of all, getting hardware support at a decent > level. From a billion of personal computers in the world, we could > easily support the most common hardware without need to develop > complex drivers or different HALs. Even SATA would not really be a > strong requirement, since most of PCs have IDE compatibility mode, > which many non-technical people even forget to switch to "SATA" mode > in the BIOS when installing their Windows OS! Again Linux's > philisophy could help us: they are proud that their hardware is Linux- > compatible, while we are embarrased that "our OS doesn't support > specific hardware". Feel the difference. Yes its a mental shift, but a hard one to adopt. ReactOS having more value over other operating systems is the selling point. Linux has been able to show its value over Windows in certain situations, and that value is greater than the hardware support value. An example, Google runs Linux, Google could not have built its network running Windows due to licensing costs. Therefore Linux has more value than Windows in that situation. It makes it worth the effort to find hardware that is Linux compatible. ReactOS related comments at the end > What we thought would work good so far is a list of working apps. As > Olaf said: "it'll be ugly, not scientifically statistically fine, > crude comparing to wine appdb and limited. Bit it can be done". The > amount of text to enter for an app entry must be as minimal as > possible: app name, platform (real hardware, emulator), bug number in > bugzilla for possible issues (max. 2 bugs for one entry). > Also, no division for "installs, but doesn't start" or "works only > via manual installation". Either it works, or it doesn't, no > intermediate stages. > As we thought later, it may even be just three columns: appname, ROS > revision, Comments. I agree with this. All software has bugs. I think the (Works/Does Not Work) is a point of view, of 'can I use this software even with its bugs?'. If yes, then it works. If not, then it does not work. Now back to the value thing. Windows costs money, ReactOS can now run hardware GL and Wine DirectX in select virtual machines. If you want to show the value of ReactOS its time to make ReactOS run as many Windows games as possible in these virtual machines on Apple Hardware. This will save OS X users the need to dual boot or acquire a Windows license. Also hardware support is not a big problem, which again helps us. This is the future. -- 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
