Well, Windows and ReactOS ARE using unix time. Not in the kernel, but in
the crt.
And actually this IS an issue on reactos at this time.
Windows has solved the issue, by adding 64 bit time_t support, which is
used by default and can only be overridden with defining
USE_32BIT_TIME_T when compiling
Can you explain, why the variables need to be volatile? This looks like
a SEH problem.
mjmar...@svn.reactos.org schrieb:
Author: mjmartin
Date: Fri Apr 17 13:59:03 2009
New Revision: 40557
URL: http://svn.reactos.org/svn/reactos?rev=40557view=rev
Log:
- Add volatile to variables in
Michael Martin wrote:
I submitted the same changes to wine. Do we need to revert and wait till they
make the changes, which may very well be different?
Even though I usually frown upon static variables myself, can you explain why
using a static variable here a bad idea?
Because the code
Don't worry it's in the branch only. :)
Ged schrieb:
I have the code to complete this functionality locally, I just haven't
committed it yet as it's not tested.
Thanks for the conflict :-P
-Original Message-
From: ros-diffs-boun...@reactos.org
Ok before you go on in this area, I am currently working on a complete
rewrite of sysparams stuff. It should hopefully be ready this week and
should fix almost all winetests and additional tests in this area.
Regards,
Timo
dchapys...@svn.reactos.org schrieb:
Author: dchapyshev
Date: Mon May 25
hyper...@svn.reactos.org wrote:
Author: hyperion
Date: Tue Jun 16 04:24:26 2009
New Revision: 41421
URL: http://svn.reactos.org/svn/reactos?rev=41421view=rev
Log:
modified dll/win32/srclient/srclient_main.c
What the hell, Arch Blackmann? windef.h, winbase.h and winnls.h are
not
This is what I found:
MSCV 2008 Epress:
stdarg.h: includes vadefs.h
vadefs.h: defines va_list
vadarg.h: 1st includes crtdefs.h, then defines va_list
crtdefs.h: 1st includes vadefs.h, 2nd defines va_list
WDK 2008 / WDK Win7:
stdarg.h: 1st includes crtdefs.h, 2nd includes vadefs.h
vadefs.h: 1st
sginsb...@svn.reactos.org wrote:
Author: sginsberg
Date: Wed Jun 17 16:44:05 2009
New Revision: 41436
[...] Because gcc is awesome we can then check for debug compilation with
both #ifdef DBG and #if DBG (error free! yay gcc!), and so we have mixed
usage all over the tree
MSVC behaves
tam...@algonet.se schrieb:
timo.kreuzer wrote:
This is what I found:
[...]
So, essentially, what you found is that all versions you looked at,
did indeed define va_list if stdarg.h was included?
essentially I found that all versions define it crtdefs.h
The question is if we
jimta...@svn.reactos.org schrieb:
Author: jimtabor
Date: Sun Jul 5 06:21:35 2009
New Revision: 41776
URL: http://svn.reactos.org/svn/reactos?rev=41776view=rev
Log:
- Implement the client shutdown procedure. Tested with wine user32 msg
undocumented 0x3B tests. Wine tests: msg: 6175 tests
jimta...@svn.reactos.org wrote:
Author: jimtabor
Date: Thu Jul 16 21:34:42 2009
New Revision: 41994
URL: http://svn.reactos.org/svn/reactos?rev=41994view=rev
Log:
- Fix fixed math, thanks Lentin.
Modified:
trunk/reactos/subsystems/win32/win32k/ntuser/class.c
Modified:
Yeah it looks promising. I love it. I will join in now, too. Let us all
work on this great idea to get it ready for the next release.
It will finally make our crappy win32k absolete. And it will fix the kernel!
;-P
James Tabor wrote:
Hi!
I'm for this! With many reasons not to post here.
Hi,
Some people might have already noticed that I have a strong opinion
regarding this rewrite. So let me explain my point of view here.
Aleksey, thanks for clarification and confirming a lot of what I already
thought. I hope you don't feel offended (at least not more than I was,
when browsing
.
--Original Message--
From: KJK::Hyperion
Sender: ros-dev-boun...@reactos.org
To: ReactOS Development List
ReplyTo: ReactOS Development List
Subject: Re: [ros-dev] Arwinss
Sent: Jul 20, 2009 8:47 AM
Timo Kreuzer wrote:
Wine emulates the kernel through a server. Of cause we don't use
Hi,
Some dlls cannot be properly tested on Window. These are:
ntdll: it uses direct systemcalls and the system call numbers would need
to match the windows system you test it on. If you are very lucky you
could find one version of win2k3 that matches our syscalls, but I
wouldn't bet on that.
Oh, c'mon, people.
This diagram says nothing.
Has anyone of you even a clue of how it would look like for Windows?
The only difference to Windows design that can be seen from this diagram
is the addition of the NT driver and X11 driver.
What it doesn't show is where which parts of the subsystem
:31:29 2009
@@ -4,78 +4,62 @@
* FILE:
subsystems/win32/win32k/dib/i386/dib32bpp_colorfill.c
* PURPOSE: ASM optimised 32bpp ColorFill
* PROGRAMMERS: Magnus Olsen
+ * Timo Kreuzer (timo.kreu...@rectos.org)
*/
- .globl _DIB_32BPP_ColorFill
yeah ;-)
Dmitry Gorbachev wrote:
Bug?
ULONG lDelta, cx, cy;
if (cx = 0)
return TRUE;
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Michael Steil wrote:
I wonder, has either of you, Alex or Timo actually *benchmarked* the
code on some sort of native i386 CPU before you argue whether it
should be a stosb or a stosd? If not, writing assembly would be a
clear case of premature optimization.
I did. on Athlon X2 64,
not need a profiler, the
linker will do the static analysis.
Also, to everyone sayings things like I was able to save a operand
name here, I hope you understand that smaller != faster.
On 4-Aug-09, at 10:13 AM, Timo Kreuzer wrote:
Michael Steil wrote:
I wonder, has either of you
hpous...@svn.reactos.org wrote:
Author: hpoussin
Date: Sat Aug 8 23:11:40 2009
New Revision: 42538
URL: http://svn.reactos.org/svn/reactos?rev=42538view=rev
Log:
Fix some typos and make PFILE a ULONG
I hope this is fully 64 bit compatible...
I think FILEID would look better and is less
Hi,
I tried to access the webtest manager http://79.99.5.181/testman/ works
but seems to be outdated, 42522 being the last revision.
http://www.reactos.org/testman/ doesn't show any revisions.
Regards,
Timo
___
Ros-dev mailing list
lol+1!
sginsb...@svn.reactos.org wrote:
Author: sginsberg
Date: Fri Aug 21 17:57:26 2009
New Revision: 42829
URL: http://svn.reactos.org/svn/reactos?rev=42829view=rev
Log:
[...]
- NDIS: Don't use floating point arithmetics in kernel mode -- spotted by
MSVC trying to link to ftol (gcc
Hi,
Ged Murphy wrote:
Firstly, that text is written for usenet not email, which IMO is both
It's a mailing list. So it's closer to usenet than to normal email IMO.
ancient and very unix orientated.
What does usenet have todo with unix?
Secondly, it's rather difficult to write emails
Aleksey Bragin wrote:
2. What is everyone up to right now, what unfinished work you have,
what work you are about to finish, what you want and what you don't
want to go to the next release? No need to write time consuming
paragraphs of course, just provide a very quick overview / status
Hervé Poussineau wrote:
Will you keep Gui On Demand functionality?
Yes, GUI on demand works with my current code already (doesn't work in
trunk). Switching back doesn't yet work, but I will try to fix this, too.
Timo
___
Ros-dev mailing list
CurInfo is an overengineered reactos construct. Mouse stuff is only
relevant for an interactive Windowstation and there is only one per
session. This way is correct,.but using the global variable
gspv.bMouseBtnSwap directly would be better.
Regards,
Timo
mkup...@svn.reactos.org schrieb:
Why are you duplicating the value? Is that needed for something?
And in case of SPI_SETMOUSECLICKLOCK pvParam is not a pointer to a BOOL,
it is the BOOL value itself.
mkup...@svn.reactos.org schrieb:
Author: mkupfer
Date: Wed Oct 7 16:25:52 2009
New Revision: 43325
URL:
Why was that reverted? It was a correct fix.
jimta...@svn.reactos.org schrieb:
Author: jimtabor
Date: Thu Oct 15 07:23:06 2009
New Revision: 43475
URL: http://svn.reactos.org/svn/reactos?rev=43475view=rev
Log:
- Revert 43470.
Modified:
trunk/reactos/include/psdk/wsahelp.h
One thing related to this is the sepeartion of the SDK part.
Curently the SDK is integral part of the whole source tree. One minor
change can cause massive rebuilds even if not needed. The import
libraries are even part of the modules that export the functions which
is stupid, because the
Christoph von Wittich schrieb:
codeblocks backend is useless as codeblocks lacks lots of features
required to build reactos
But it should be enough to build some usermode apps, or not?
Anyway CodeBlocks can import MSVC projects, so it wouldn't be a huge
loss I guess.
Alexander Potashev wrote:
Hi,
Ok, commenting here...
MSDN says that Mm64BitPhysicalAddress is PBOOLEAN:
http://msdn.microsoft.com/en-us/library/bb648424.aspx
So, there should be another BOOLEAN variable, and
Mm64BitPhysicalAddress should point to it.
No, that's just because of the way
Warning in cases in which the compiler doesn't know whether something is
correct or not, is stupid in any case IMO, unless it's some
--enable-uber-pedantic-warnings compiler flag. It could as well say
warning: your code could be wrong and by chance this might be true.
Dmitry Gorbachev wrote:
Hi,
I worked with TortoiseHg some time, I thought I could get used to it,
but to no avail.
From my experience, I can only say that almost *everything* is non
trivial or doesn't work Apart from the shitty interface.
I just tested the latest version again, it's completely unintuitive, and
merging
system libraries
* FILE:lib/rtl/bitmap.c
* PURPOSE: Bitmap functions
- * PROGRAMMER: Eric Kohl
+ * PROGRAMMER: Timo Kreuzer (timo.kreu...@reactos.org)
*/
/* INCLUDES
*/
@@ -12,965 +13,749
Relax, dude ;-P
The changes I made were the following:
1.) removed EFLAGS_ZERO and EFLAG_SIGN as they are part of winddk. Any
reason to have them in the NDK, too?
2.) added EFLAGS_PF, EFLAGS_AF, EFLAGS_SF, EFLAGS_OF, EFLAGS_IOPL_MASK,
EFLAGS_RF, EFLAGS_ID just for completeness.
3.) renamed
Gregor Schneider wrote:
I'm pretty much sticking to the way it is done in most other places.
Ref:
http://git.reactos.org/?p=reactos.gita=searchh=HEADst=greps=ZeroInit
I can only see
ApiMessage.h.u2.ZeroInit = 0
___
Ros-dev mailing list
I don't see any use in renaming the WINDOW_OBJECT structures.
spwndXxx means shared pointer to a WND, this does not reflect it's
current usage in WINDOW_OBJECT.
We already have a WND and it has spwndXxx members and they are in use.
You should rather try to get rid of them completely inside
Thinking about the changelog problem, I had the following idea:
On the website there would be a place maybe called myDevelopment or
something. Here you would automatically find a list of all your recent
commits. Seperated by release version. By default every new commit
creates a new entry here.
Alex Ionescu schrieb:
I still don't see how writing such a webservice + figuring out how to use it
is simpler than just dumping your user log and copy/pasting the entries with
a little bit of formatting cleanup.
Why do people bother figuring out how MSVC works, when they can as well
write
Prove what? That there's documentation or that it's usable for x86, too?
Or is that a coding challenge?
Alex Ionescu wrote:
Prove it.
On 2009-12-30, at 7:48 AM, Timo Kreuzer wrote:
Also there is documentation for
the newer interface available and it's usable for x86 later, too
=enclient=safarirls=enq=%22x86BiosCall%22+site%3Amicrosoft.comaq=foq=aqi=
Your search - x86BiosCall site:microsoft.com - did not match any documents.
bash-3.2$ grep -ir 'x86BiosCall' /ntdev/headers/ --include *.h --include *.c
bash-3.2$
Your turn.
On 2009-12-30, at 12:23 PM, Timo Kreuzer
The output on the screen is well known and documented. And was at that
time, too, as it could be seen pretty often. There's nothing secret. and
there's only 2 cases that need to be considered by analyzing the NMI
status register, which is also well known and documented. There are
magic numbers,
Daniel Reimer schrieb:
And why? log2lines does the same job and much more. Nothing really
changes for the users, the command still is called raddr2line.
Oh, ok, nvm then ;)
___
Ros-dev mailing list
Ros-dev@reactos.org
Ros Arm wrote:
Hi Timo,
Regarding #1, we actually have this working in our tree. It was required for
the new SYSENTRY C handler. So thank you for the advice and for pointing that
out. Unfortunately I will not credit you for the idea since the code was
already written, I hope this is
I gave up on arguing. Instead I'll just use this to push my own ideas.
I also have a secret plan of a Complete rewrite that will bring
ReactOS to the next level not yet sure about the details, but I think
it will incorporate something like virtualization and cloud computing.
*muahahaha*
You seem to be using an outdated source code version.
include/reactos/wine/winuser.h:12:1: warning: DCX_USESTYLE redefined
We don't even have this file since August 2009
Please download latest version of the source code and try again.
Sources of 0.3.11 release:
James Tabor schrieb:
Timo told me. So it must build in 32 bit mode and boot.
Oops my fault, I guess :)
I thought you were joking when talking about the branch. That's why I
said it doesn't have the kernel problems of trunk and there is no region
leak. Because the 64 bit code it is neither
No doubt the new code is a huge advantage over the old code. Still there
are some issues in my opinion.
Currently the trap handlers are generated inside C code by a macro
called KiTrap(), located in trap_x.h.
This macro creates a C function, that uses KiTrapStub inline function to
create the
While the idea of sharing code between hal and freeldr is good, I think
the current approach is not the best. so far it caused recompilation for
a lot of hal code and added a lot of support code and only very few
shared code.
I would suggest to implement an x86 Hw / Bios library, containing the
Maybe this is also a good occasion to actually fix buildbot to not build
branches(?)
Btw, before people start complaining that I committed to ta branch and
caused more work for buildbot... I didn't, my revs are canceled and I'm
going to continue doing that until the bot's back. Stopping the
Hi,
I have a pending rewrite of the driver loading code in
branches/reactos-yarotows.
It should hopefully fix the issues and load eVb's driver.
It's mostly done, I experienced some random lock ups, though and had to
take a break from that code.
Regards,
Timo
sir_rich...@svn.reactos.org schrieb:
Hi,
I skimmed through ddk/ndk and the only fastcall function I could find,
that passes anything else then a pointer, enum or native integer type is
RtlUlonglongByteSwap, passing a ULONGLONG, but that is the only
parameter, and gcc and msvc do the same here, passing it on the stack.
But at least
Hi,
The testcd is broken. And no, it's not due to the header merge. This
time it broke in r46574 (hal changes)
Now please don't blame sir richard, instead someone please free some
disk space on the testbot.
Regards,
Timo
___
Ros-dev mailing list
*This* is a valid commit message ;-)
Log:
[HAL]: Fucken' A, I knew I'd forget one.
Ged Murphy wrote:
This is not a valid commit message...
-Original Message-
From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On
Behalf Of jgar...@svn.reactos.org
Sent:
+
+#define GDIOBJ_GetKernelObj(Handle) \
+
((PGDI_TABLE_ENTRY)GdiHandleTable-Entries[GDI_HANDLE_GET_INDEX(Handle)])-KernelData
This function shouldn't even exist.
pdcattr-hlfntNew = NtGdiGetStockObject(SYSTEM_FONT);
TextIntRealizeFont(pdcattr-hlfntNew,NULL);
+
That's probably a good Idea, but I still like to point out, you cannot
tell anyone what to do.
You can put up a list of what's important/required and I'm likely to
pick something from it from time to time.
You can ask me to do something and I might be like *sigh*, well ok...
(halfassed attempt
Andrew Faulds wrote:
Yes. We need a Linus Torvalds for ReactOS. If it worked for Linux, it'll
work for ReactOS.
No. A trunk manager selecting what he likes won't work for reactos,
because we just don't have enough devs for any kind of cherry picking.
We need to take what we get. It would
AFAICR, support for C::B was dropped, you should - in theory - be able
to import VC project files.
Sir Gallantmon wrote:
C::B support is currently broken at this time. It needs to be revised to
support the newest Code::Blocks project format...
On Sat, Apr 17, 2010 at 6:28 PM, Alexey Komarov
It's not about wrong or right or compatibility.
It's a name. For a constant of value 1024*1024. We could rename it to
_1MiB.
But does that really help anyone? I'm sure it would rather confuse
people, as a lot of people sadly don't know the difference.
Also from a scientifical perspective it's
Aleksey Bragin wrote:
On May 1, 2010, at 7:57 AM, James Tabor wrote:
I'm reacting to when it gets broken! I could be wrong and when I am I
do admit it openly! But, you need to read bug 5265. I guess we can
revert all the gdi batch code to fix it. Yes it fixes it but still the
real problem
Jan Blomqvist Kinander wrote:
Hi Developers, I have been aproached by a certain Gonzalo from Colombia, he
claims to be a developer who wants to make a Terminal Server Clone, I enclose
the mail he sent me, please have a look at it and answer him.
Yours Sincerely,
Jaix Bly
I'll reply
test if the list works ;-)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
ahmet alper parker wrote:
Why kindly supply some more technical answer
instead of joking?
In theory ReactOS ntoskrnl can be loaded by ntldr from Windows 2003.
Together with reactos hal it might actually boot (for a low enough
value of boot). You would also need reactos ntdll, as it's
Ged Murphy wrote:
I've spoken to Mike about this, apparently the lock is held much
higher in the call chain (EnterUserExclusive), which isn't obvious in
the patch.
Sounds like a pretty inefficient lock though.
Yes and exactly the way it's done in Windows. All USER code is guarded
by one huge
After Olaf's mentioning of increased buildtimes I'd like to throw 2
different, independent and major changes to our build process into
discussion. One is about rbuild and one is about the file layout. I'd
like to start with the rbuild related topic.
What I suggest only for consideration, is a
Make a little now. And I think I have to correct my first impressions. I
quickly noticed that the syntax is completely retarded, but as it's a
macro language, I thought I could work around these problems. But there
are some limitations especially regarding dependencies that seem to be
hard to
Sylvain Petreolle wrote:
I fully agree on this.
This will also remove the need to rebuild the dll (and possibly other
dependant modules)
if we have to disable a registration for testing/debugging purposes.
Speaking of dlls and dependencies: I think our current approach (all
modules depend
Hi
I'd like to propose a small change: converting freeldr into a PE file.
The current freeldr / setupldr are raw binaries, which makes them easy
to handle for the bootsector but it disqualifies them from proper
debugging with gdb. A solution is to convert them into PE format. As
there is no
Brian Palmer schrieb:
IIRC, there is currently some extra boot code prepended to the beginning of
the FreeLoader binary to assist the bootsector on certain file systems. Does
converting to PE format cause any problems for this?
Yes, you are right, this might cause problems. I'll look into
Hi,
I'd like to announce that as of r48278, you can build a full x64 bootcd
(including rostests, not rosapps) from trunk.
That means from now on, I can quickly see when someone breaks 64 bit
compatibility: http://reactos.ath.cx:8081/waterfall
So please don't cast PVOID to ULONG ;-)
Regards,
I think we can simply sync freetype then the hinting code will be on by
default
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Aleksey Bragin wrote:
Please, this would be my last reply to this thread. Yet another time
I'm getting an answer that reshuffling files in the directory makes
build time shorter. Seriously, am I writing with background and
foreground text colors being set to the same value or what?
Is
+MACRO (MACRO_ADD_DXSDK_INTERFACES)
+
+ FOREACH(_in_FILE ${ARGN})
+
+ GET_FILENAME_COMPONENT(FILE ${_in_FILE} NAME_WE)
+
+ ADD_CUSTOM_COMMAND(
+ OUTPUT ${REACTOS_BINARY_DIR}/include/dxsdk/${FILE}.h
+ COMMAND native-widl -I${REACTOS_SOURCE_DIR}/include/dxsdk -I.
fireb...@svn.reactos.org schrieb:
- Fix incorrect function definitions. To be submitted upstream.
I remember just recently joking about all our Needs to be ...,
Someone should ..., Please someone ... commit messages, which
usually mean I'm too lazy to ... and result in things never being
Jérôme Gardou schrieb:
That's why I began to revert all of this stuff, which is horrible :-)
While I completely agree on removing BITMAPCOREHEADER support, I don't
really like other parts.
- Probing the BITMAPINFO and then passing the usermode buffer to the
internal and unprotected function is
Jérôme Gardou wrote:
- Probing the BITMAPINFO and then passing the usermode buffer to the
internal and unprotected function is not enough. The buffer must be
copied.
OK, it's safer this way.
It's not a matter of safe, safer, safest. It's wrong vs correct.
Accessing the usermode buffer
Hi,
Please take care about proper protection of the user mode buffer. The
current solution: probe and forget is not safe.
Possibilities are:
1) SEH protected copying of the buffer, pass the copy of the buffer to
lower level functions - Easy to do, large overhead for large bitmaps.
2) SEH
Aleksey Bragin schrieb:
In my opinion, we should list every source file to be included to
prevent unexpected side effects.
Actually I think listing *every* source file is not really the best
way, because most of the build modules include all of their respective
source files, with the only
It looks like this change has caused some regressions in sysreg
http://www.reactos.org/testman/compare.php?ids=3934,3935
cgut...@svn.reactos.org wrote:
Author: cgutman
Date: Sun Aug 22 22:22:27 2010
New Revision: 48593
URL: http://svn.reactos.org/svn/reactos?rev=48593view=rev
Log:
Hi
I'd like to propose an overhaul of our bugzilla interface. The reason is
that the current interface is ugly and confusing and I think we can make
filing and handling bugs less unenjoyable ;-)
First I think it would be very useful, if we could edit the description
field of the bugs. This way
Alex Ionescu wrote:
This is retarded,
That's your opinion.
Why did this require rewriting everything in ATT syntax and introducing
bugs?
It doesn't. Noone said it does.
And what's up with calling ATT syntax GAS Syntax.
Yes, what's up with that?
I wonder what Brian would say
And btw: the one who did the mistake was one of our newest developers,
Arty, who might still lack of experience in the field of programming.
Let's hope he didn't make 5 more old developers leave now ;-)
___
Ros-dev mailing list
Ros-dev@reactos.org
Pierre Schweitzer wrote:
Hi,
while working on GPT handling for ReactOS, one thing appeared: Microsoft (at
least in Windows 2003 SP1) is using hardcoded partition entry size, ie it
assumes that every partition entry in GPT will be 128 bytes big. Even if that
assertion is largely right, it
Ros Arm wrote:
Hello,
After the switch in 48124 to PE FreeLDR, I am unable to boot FreeLDR any
longer.
I have tried official, as well as various unofficial freeldr.sys, none worked.
47892 version works fine, 48124 does not.
On a 512MB IDE disk, I got the _ VGA cursor scrolling
sir_rich...@svn.reactos.org wrote:
Author: sir_richard
Date: Mon Sep 20 06:30:21 2010
New Revision: 48825
+ !-- FIXME: workarounds until we have a proper oldnames library --
+define name=lseek_lseek/define
+define name=read_read/define
+define name=strdup_strdup/define
Brian Palmer schrieb:
It seems there are some severe technical limitations to a PE FreeLoader.
Can you please elaborate on that? What limitations are there?
I can only see one minor limitation: Booting from a floppy or harddisk
with FAT16, which is smaller than 300MB, where freeldr gets
Olaf Siejka wrote:
It might be helpful but otoh, it would delay release even futher, two
weeks minimum in my opinion... and even more if serious regressions
happen. Is it worthy to do a winesync before release? We do risk
regressions and bugs a lot.
I agree that it's a risk.
IMO we should
I second that. What about simply using the C preprocessor?
Regards, Timo
Matthias Kupfer wrote:
HI,
recently I had to alter some inf-files for fixing a bug. At present we have
for each platform (i386, arm, amd64) separate files, which are hard to
maintain because of some identical, that
That will be hard to beat for r5...
Author: sir_richard
Date: Tue Oct 5 15:59:47 2010
New Revision: 49000
URL: http://svn.reactos.org/svn/reactos?rev=49000view=rev
Log:
[NTOS]: Fix whitespace typo in comment (two spaces instead of one).
That's right. I'm not a fun person.
Am 23.10.2010 11:21, Olaf Siejka wrote:
How will you convince anyone that such setup on ReactOS is of any
worth to be used and what is more important - better to be used over
similar linux setups?
Right now we dont have enough manpower to keep testing ROS on a most
basic level (its over a
Hi everyone,
I'd like to announce that I'm soon going to merge yarotows back into
trunk, if no other regressions are found. The current issues (red icons
and blue text on disabled buttons will be fixed, Kamil has already a fix.)
Last chance to test and object ;-)
Regards,
Timo
The problem is missing MmSecureVirtualMemory. The new Mm code is a big
step into this direction, so I guess it won't take long until it's
implemented. Until that we can probably live with the hack.
Am 25.10.2010 20:43, schrieb Gregor Schneider:
Hi,
good to see the branch work back in trunk,
Am 26.10.2010 18:01, schrieb jgar...@svn.reactos.org:
+#ifdef __GCC__
/* Note: this should return a CLIENT_CALL_RETURN, but calling convention for
* returning structures/unions is different between Windows and gcc on i386.
*/
LONG_PTR RPC_VAR_ENTRY
@@ -659,6 +663,13 @@
Aren't you confusing build time dependencies with run time dependencies
here?
Am 30.10.2010 11:22, schrieb jgar...@svn.reactos.org:
Author: jgardou
Date: Sat Oct 30 09:22:55 2010
New Revision: 49346
URL: http://svn.reactos.org/svn/reactos?rev=49346view=rev
Log:
[CMAKE]
- jscript
First thanks for your detailed analysis. I have looked into this problem
some time ago as well and I found a website, which documents this
behaviour here:
http://www.delphi-forum.de/viewtopic.php?p=290872sid=90dd5488f7ea8262bcf37e3a4204a8ea
(German, sorry)
The parameters passed for these delphi
Am 03.11.2010 09:27, schrieb Adam Kachwalla:
Although it seems completely non-functional in the latest trunk
builds. Start menu doesn't work, etc.
It used to work quite well in Windows though.
___
Ros-dev mailing list
Ros-dev@reactos.org
Am 05.11.2010 14:43, schrieb Timo Kreuzer:
The changes are between r7324487 and r7281232.
I mean r49229 and 49472 ;-)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
I have thought about the multiple Windows version thing some time ago
and had some ideas.
One idea is to Reorganize the functionality, similar to the way it's
done in Windows 7.
some of the win32 dlls would become wrapper dlls and forwarding to the
actual implementations. These wrapper dlls would
Am 13.11.2010 12:31, schrieb Ged Murphy:
Microsoft already provide similar technology known as virtual dlls.
It was a technology designed for MinWin.
They split functionality of dlls into ?api sets? These can be seen in
Win 7 in the system32 dir with the prefix ?api-ms-win-core--num
1 - 100 of 392 matches
Mail list logo
