Re: [ros-dev] Dynamic libxml2/zlib

[Christoph von Wittich]

Any 3rd party apps which could overwrite these with an incompatible version?

Christoph 

Gesendet von meinem Windows 10 Phone

Von: Thomas Faber
Gesendet: Samstag, 3. Februar 2018 13:35
An: Amine Khaldi
Cc: ReactOS Development List
Betreff: [ros-dev] Dynamic libxml2/zlib

Hey Amine,

seeing https://jira.reactos.org/browse/CORE-14288 just prompted me to
look into static vs dynamic 3rd party libraries, zlib and libxml2 in
particular. We use zlib in a bunch of modules these days, and libxml2 is
large and used in two, so I'm thinking we should make them dynamic.

I just did the experiment for libxml2 and it resulted in at least 0.5MB
binary size reduction and 2MB build folder size reduction, so clearly
seems worth it.[1] I'll do the test for zlib as well to make sure that's
also an improvement.

However I was thinking there might be a reason why we build those
statically right now. Do you (or anyone else) recall anything that makes
switching to dynamic a bad idea?

Thanks!
-Thomas


[1] Raw results:
Static libxml2 (MSVC debug with RTC):
msxml3.dll - 1887 KB
libxslt.dll - 1142 KB
libxml2.lib - 4953 KB (build dir only)

Dynamic libxml2 (MSVC debug with RTC):
msxml3.dll - 799 KB
libxslt.dll - 259 KB
libxml2.dll - 1592 KB
libxml2.lib - 371 KB (build dir only)

Static libxml2 (GCC debug with -O1):
msxml3.dll - 3856 KB
libxslt.dll - 2776 KB
liblibxml2.a - 48 KB (build dir only)

Dynamic libxml2 (GCC debug with -O1):
msxml3.dll - 1505 KB
libxslt.dll - 429 KB
libxml2.dll - 2553 KB

___
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

Re: [ros-dev] MSVC and GCC Windows Buildslaves are back - old ISOs are not

[Christoph von Wittich]

What about deduplication?

Am 04.10.2016 um 22:10 schrieb Colin Finck:

Hi all,

Thanks to Dmitry Chapyshev's generous donation of rare FB-DIMM memory
modules, our Buildserver has enough RAM for the Win7 buildslave VM now.

I've fired it up and while builds are much slower than before, they are
at least being done again!
Note that Doxygen, ISO hosting, and all three buildslaves are on a
single HDD-backed server right now, so don't expect any performance
miracles.
I'm counting on Aleksey here to get us our remaining servers back this
month :)

Unfortunately, our HDDs were also lacking space, so I had to move the
public "bootcd_old" folder from iso.reactos.org to another (private)
place. It contained BootCD ISOs from 2009 to 2012, totalling 421GB.
Any idea how to deal with them in the long run? I can basically think of
4 possibilities:

* We remove ISOs older than 4 years, because nobody would really do
regression-testing with them.

* We buy additional HDDs every year and continue to host them ourselves
just next to the newer ISOs.

* We find a free file hosting service for OSS projects that can cope
with these amounts of data. Not sure SF.net is the right choice here..

* We choose a paid data storage service like Amazon AWS.

As always, comments are very welcome!


- Colin

___
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

Re: [ros-dev] [ros-diffs] [cwittich] 72792: [CRYPTNET] disable broken code

[Christoph von Wittich]

CreateFileA("C:C:\\Windows", GENERIC_READ, FILE_SHARE_READ,
 NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
ok( GetLastError() == ERROR_INVALID_NAME, "Wrong LastError %d, 
expected ERROR_INVALID_NAME\n", GetLastError() );


Our CreateFile is right...

Am 24.09.2016 um 17:22 schrieb Christoph von Wittich:
I guess CreateFile in wine doesn't return the correct LastError when 
you pass an invalid path like "C:C:\Windows"
Our CreateFile returns ERROR_INVALID_NAME, wines PATH_NOT_FOUND or 
FILE_NOT_FOUND**


Guess we need a test for CreateFile...

Am 24.09.2016 um 17:10 schrieb Thomas Faber:

What's the symptom you're trying to fix?
Is it a problem for Wine also, or just for us? And why?

Trying to understand why we need to break Wine sync here.


On 2016-09-24 17:01, Christoph von Wittich wrote:

It won't work for absolute paths as it will result in C:C:\folder\. I
committed a better fix.


Am 24.09.2016 um 13:56 schrieb Thomas Faber:

Could you elaborate on what makes it broken? Link to a bug perhaps?

On 2016-09-24 13:39,cwitt...@svn.reactos.org  wrote:

Author: cwittich
Date: Sat Sep 24 11:39:17 2016
New Revision: 72792

URL:http://svn.reactos.org/svn/reactos?rev=72792=rev
Log:
[CRYPTNET] disable broken code

Modified:
  trunk/reactos/dll/win32/cryptnet/cryptnet_main.c

Modified: trunk/reactos/dll/win32/cryptnet/cryptnet_main.c
URL:http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/cryptnet/cryptnet_main.c?rev=72792=72791=72792=diff
==
--- trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] (original)
+++ trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] Sat Sep 24 
11:39:17 2016
@@ -1025,6 +1025,7 @@
components.dwUrlPathLength + 1);
   hFile = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+#ifndef __REACTOS__
   if (hFile == INVALID_HANDLE_VALUE)
   {
   /* Try again on the current drive */
@@ -1049,6 +1050,7 @@
   }
   }
   }
+#endif
   if (hFile != INVALID_HANDLE_VALUE)
   {
   if ((ret = CRYPT_GetObjectFromFile(hFile, pObject)))



___
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



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [cwittich] 72792: [CRYPTNET] disable broken code

[Christoph von Wittich]

I guess CreateFile in wine doesn't return the correct LastError when you 
pass an invalid path like "C:C:\Windows"
Our CreateFile returns ERROR_INVALID_NAME, wines PATH_NOT_FOUND or 
FILE_NOT_FOUND**


Guess we need a test for CreateFile...

Am 24.09.2016 um 17:10 schrieb Thomas Faber:

What's the symptom you're trying to fix?
Is it a problem for Wine also, or just for us? And why?

Trying to understand why we need to break Wine sync here.


On 2016-09-24 17:01, Christoph von Wittich wrote:

It won't work for absolute paths as it will result in C:C:\folder\. I
committed a better fix.


Am 24.09.2016 um 13:56 schrieb Thomas Faber:

Could you elaborate on what makes it broken? Link to a bug perhaps?

On 2016-09-24 13:39, cwitt...@svn.reactos.org wrote:

Author: cwittich
Date: Sat Sep 24 11:39:17 2016
New Revision: 72792

URL: http://svn.reactos.org/svn/reactos?rev=72792=rev
Log:
[CRYPTNET] disable broken code

Modified:
  trunk/reactos/dll/win32/cryptnet/cryptnet_main.c

Modified: trunk/reactos/dll/win32/cryptnet/cryptnet_main.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/cryptnet/cryptnet_main.c?rev=72792=72791=72792=diff
==
--- trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] (original)
+++ trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] Sat Sep 24 
11:39:17 2016
@@ -1025,6 +1025,7 @@
components.dwUrlPathLength + 1);
   hFile = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+#ifndef __REACTOS__
   if (hFile == INVALID_HANDLE_VALUE)
   {
   /* Try again on the current drive */
@@ -1049,6 +1050,7 @@
   }
   }
   }
+#endif
   if (hFile != INVALID_HANDLE_VALUE)
   {
   if ((ret = CRYPT_GetObjectFromFile(hFile, pObject)))




___
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

Re: [ros-dev] [ros-diffs] [cwittich] 72792: [CRYPTNET] disable broken code

[Christoph von Wittich]

It won't work for absolute paths as it will result in C:C:\folder\. I 
committed a better fix.



Am 24.09.2016 um 13:56 schrieb Thomas Faber:

Could you elaborate on what makes it broken? Link to a bug perhaps?

On 2016-09-24 13:39, cwitt...@svn.reactos.org wrote:

Author: cwittich
Date: Sat Sep 24 11:39:17 2016
New Revision: 72792

URL: http://svn.reactos.org/svn/reactos?rev=72792=rev
Log:
[CRYPTNET] disable broken code

Modified:
 trunk/reactos/dll/win32/cryptnet/cryptnet_main.c

Modified: trunk/reactos/dll/win32/cryptnet/cryptnet_main.c
URL: 
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/cryptnet/cryptnet_main.c?rev=72792=72791=72792=diff
==
--- trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] (original)
+++ trunk/reactos/dll/win32/cryptnet/cryptnet_main.c[iso-8859-1] Sat Sep 24 
11:39:17 2016
@@ -1025,6 +1025,7 @@
   components.dwUrlPathLength + 1);
  hFile = CreateFileW(path, GENERIC_READ, FILE_SHARE_READ,
   NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+#ifndef __REACTOS__
  if (hFile == INVALID_HANDLE_VALUE)
  {
  /* Try again on the current drive */
@@ -1049,6 +1050,7 @@
  }
  }
  }
+#endif
  if (hFile != INVALID_HANDLE_VALUE)
  {
  if ((ret = CRYPT_GetObjectFromFile(hFile, pObject)))




___
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

Re: [ros-dev] wtf iso.reactos.org is down for ages?

[Christoph von Wittich]

Should work again.

Am 06.12.2015 um 16:54 schrieb Sylvain Petreolle:

Are there any updates ?
This blocks me from fixing network bugs, testman lacks the last 20 
commits results.

Kind regards, Sylvain Petreolle


*De :* Colin Finck 
*À :* ros-dev@reactos.org
*Envoyé le :* Samedi 5 décembre 2015 6h40
*Objet :* Re: [ros-dev] wtf iso.reactos.org is down for ages?

Am 04.12.2015 um 21:22 schrieb Alexander Rechitskiy:



> wtf iso.reactos.org is down for ages?


All I can say is that we currently have no access to the entire network
in our Sweden data center. It may be caused by a power or ISP outage,
but I'm just guessing here.
I expect our administrator to look at it after the weekend.

Sorry for the inconveniences, but this is all I can do for now.

Cheers,

Colin


___
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


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [cwittich] 68305: [BROWSEUI] don't exposesome interfaces expose IID_IContextMenu3 from CBandSiteMenu

[Christoph von Wittich]

Please revert it then

- Ursprüngliche Nachricht -
Von: Pierre Schweitzer pie...@reactos.org
Gesendet: ‎29.‎06.‎2015 21:36
An: ros-dev@reactos.org ros-dev@reactos.org; Christoph von Wittich 
christ...@apiviewer.de
Betreff: Re: [ros-dev] [ros-diffs] [cwittich] 68305: [BROWSEUI] don't 
exposesome interfaces expose IID_IContextMenu3 from CBandSiteMenu

This commit regressed (badly) explorer:
https://www3.heisspiter.net/explorer.png

On 28/06/2015 20:22, cwitt...@svn.reactos.org wrote:
 Author: cwittich
 Date: Sun Jun 28 18:22:02 2015
 New Revision: 68305
 
 URL: http://svn.reactos.org/svn/reactos?rev=68305view=rev
 Log:
 [BROWSEUI]
 don't expose some interfaces
 expose IID_IContextMenu3 from CBandSiteMenu
 
 Modified:
 trunk/reactos/dll/win32/browseui/addressband.h
 trunk/reactos/dll/win32/browseui/addresseditbox.h
 trunk/reactos/dll/win32/browseui/bandsitemenu.h
 trunk/reactos/dll/win32/browseui/internettoolbar.h
 
 Modified: trunk/reactos/dll/win32/browseui/addressband.h
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/addressband.h?rev=68305r1=68304r2=68305view=diff
 ==
 --- trunk/reactos/dll/win32/browseui/addressband.h[iso-8859-1] (original)
 +++ trunk/reactos/dll/win32/browseui/addressband.h[iso-8859-1] Sun Jun 28 
 18:22:02 2015
 @@ -136,6 +136,5 @@
  COM_INTERFACE_ENTRY_IID(IID_IInputObjectSite, IInputObjectSite)
  COM_INTERFACE_ENTRY_IID(IID_IPersist, IPersist)
  COM_INTERFACE_ENTRY_IID(IID_IPersistStream, IPersistStream)
 -COM_INTERFACE_ENTRY_IID(IID_IDispatch, IDispatch)
  END_COM_MAP()
  };
 
 Modified: trunk/reactos/dll/win32/browseui/addresseditbox.h
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/addresseditbox.h?rev=68305r1=68304r2=68305view=diff
 ==
 --- trunk/reactos/dll/win32/browseui/addresseditbox.h [iso-8859-1] (original)
 +++ trunk/reactos/dll/win32/browseui/addresseditbox.h [iso-8859-1] Sun Jun 28 
 18:22:02 2015
 @@ -97,7 +97,6 @@
  COM_INTERFACE_ENTRY_IID(IID_IWinEventHandler, IWinEventHandler)
  COM_INTERFACE_ENTRY_IID(IID_IOleCommandTarget, IOleCommandTarget)
  COM_INTERFACE_ENTRY_IID(IID_IDispatch, IDispatch)
 -COM_INTERFACE_ENTRY_IID(IID_IPersist, IPersist)
  COM_INTERFACE_ENTRY_IID(IID_IPersistStream, IPersistStream)
  END_COM_MAP()
  };
 
 Modified: trunk/reactos/dll/win32/browseui/bandsitemenu.h
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/bandsitemenu.h?rev=68305r1=68304r2=68305view=diff
 ==
 --- trunk/reactos/dll/win32/browseui/bandsitemenu.h   [iso-8859-1] (original)
 +++ trunk/reactos/dll/win32/browseui/bandsitemenu.h   [iso-8859-1] Sun Jun 28 
 18:22:02 2015
 @@ -55,6 +55,7 @@
  BEGIN_COM_MAP(CBandSiteMenu)
  COM_INTERFACE_ENTRY_IID(IID_IShellService, IShellService)
  COM_INTERFACE_ENTRY_IID(IID_IContextMenu2, IContextMenu2)
 +COM_INTERFACE_ENTRY_IID(IID_IContextMenu3, IContextMenu3)
  COM_INTERFACE_ENTRY_IID(IID_IContextMenu, IContextMenu)
  END_COM_MAP()
  };
 
 Modified: trunk/reactos/dll/win32/browseui/internettoolbar.h
 URL: 
 http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/internettoolbar.h?rev=68305r1=68304r2=68305view=diff
 ==
 --- trunk/reactos/dll/win32/browseui/internettoolbar.h[iso-8859-1] 
 (original)
 +++ trunk/reactos/dll/win32/browseui/internettoolbar.h[iso-8859-1] 
 Sun Jun 28 18:22:02 2015
 @@ -228,7 +228,6 @@
  COM_INTERFACE_ENTRY_IID(IID_IInputObject, IInputObject)
  COM_INTERFACE_ENTRY_IID(IID_IOleWindow, IOleWindow)
  COM_INTERFACE_ENTRY_IID(IID_IDockingWindow, IDockingWindow)
 -COM_INTERFACE_ENTRY_IID(IID_IPersist, IPersist)
  //COM_INTERFACE_ENTRY_IID(IID_IPersistStream, IPersistStream)
  COM_INTERFACE_ENTRY_IID(IID_IPersistStreamInit, IPersistStreamInit)
  COM_INTERFACE_ENTRY_IID(IID_IOleCommandTarget, IOleCommandTarget)
 @@ -237,7 +236,5 @@
  COM_INTERFACE_ENTRY_IID(IID_IShellChangeNotify, IShellChangeNotify)
  COM_INTERFACE_ENTRY_IID(IID_IObjectWithSite, IObjectWithSite)
  COM_INTERFACE_ENTRY_IID(IID_IServiceProvider, IServiceProvider)
 -COM_INTERFACE_ENTRY_IID(IID_IWinEventHandler, IWinEventHandler)
 -COM_INTERFACE_ENTRY_IID(IID_IBandSite, IBandSite)
  END_COM_MAP()
  };
 
 


-- 
Pierre Schweitzer pierre at reactos.org
System  Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM

[Christoph von Wittich]

Does this mean Hermes just volunteered to adapt the ~130 patches in JIRA 
to his new tree structure...?


Am 06.03.2015 um 00:58 schrieb Hermès BÉLUSCA - MAÏTO:

Hi,

So first, please receive my apologies for not having warned in ros-dev about
this (continuation of) tree restructure I did starting with r66575. Indeed
this was the first thing to do before doing anything, even if I talked about
that on IRC and JIRA!

In fact, the tree restructure discussion started 5 years ago, along with the
cmake bringup: see the big thread here:
http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html . At that
time the main argument was that we were also in the middle of changing the
old build system (rbuild) to a new one (cmake) so it was problematic to do
those two big changes at once. Also at that time, seeing the argumentation
of Ged, Timo, Jérôme and the few others (active developers) who dared to
participate to this discussion, it was clear that a tree restructure was
necessary anyway, sooner or later.

In 2012 some tree restructure happened (r56305) by moving around and in a
more logical manner some core components of win32.

What happens now in 2015, i.e. 5 years after ? We have CMake well
established, everything works, but only win32 core was reorganized.

I made http://jira.reactos.org/browse/CORE-9111 , people started to give
proposals. You came back with the almost same argument, that is to finish
the existing things first (adapt that: at the time of CMake, it was CMake,
now, it's fix all ReactOS 0.4 bugs), and then improve structure of source
tree. Since not all the existing bugs will be fixed by then, we can continue
this way and wait another 5 years in order to have a real tree restructure?
I don't think so.
So I took that for granted and committed r66575.

Active developers really think (at least, myself) it's a pain in the ***
that when we code on some given module (example: shell), we need to modify
some bit of code in base/shell/whatever, some bit of code in
dll/win32/shell32, some bit of code here and there. All the code of the
shell should be tied together. This goes also for everything else: the core
of NT (kernel, ntdll, base drivers...), the win32 subsystem (win32k; for
it the change in r56305 started to make things more logical: you would not
have to modify code in some win32k/ directory while also changing
dll/win32/gdi32 or dll/win32/user32 that were by the way amongst all the
rest of wine dlls, etc...) .

Because I didn't want to wait yet another 5 years I decided to start
something.

OK my fault I would have to get a synthesis of the different proposals of
tree restructures I got, then put in ros-dev, then wait 1 month until
everybody starts to vote. Of course you would get people thinking it's
better to do à la Wine and sort the files by extension type (that's what we
almost have currently) and it was already repeated that it is BAD because it
doesn't translate the fact that ROS/windows is built by modules; others
would have thought it's nice to have this piece of thing next to another one
whereas this can be postponed later on until the *obvious* parts of code
have been properly packed together.

And because of that, here is my proposal: UNTIL details get fixed, I propose
to:
- keep the /boot/, /include/, /lib/, /media/ and /tools/ directories (as
well as /cmake/ and the files in / ) untouched.
- ntoskrnl, ntdll and the drivers we have in /drivers/ (SAUF, the multimedia
ones) go into some main ntcore directory (ntcore, ntos, call it whatever
you prefer. I'm inclined to the second name, but I'm ok with the first one).
- the keyboard layouts can be moved either to win32ss/ or to / (in case we
can give sense to keyboard layouts in pure NT, for example when we run
usetup, etc...)
- ok... my already-done (but revertable) modifs from 66575 (directory
renamings can be done, it's not set in stone).
- putting all printing support in some /win32/printsup (or printing...)
directory : that means: localspl, ntprint, printui, spoolsv and spoolss, and
winspool (so far...)

That's what I'm 99.99% sure (and what I think is quite clear). Concerning
the rest (that can create discussion) I still keep it in old directories.

Regards,
Hermès.



-Message d'origine-
De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Aleksey
Bragin
Envoyé : vendredi 6 mars 2015 00:15
À : ros-dev@reactos.org
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree
(final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM

Hermes,

What the fuck, may I ask?

I don't understand since when we started doing big changes in trunk without
talking (or listening) to anyone at all, just at your own discretion?

Are you so sure the change is accepted by majority of our developers?
Did you get approval of those devs? Give them some respect which they earned
over years with their skills and commitment.

I understand ReactOS is a very loosely managed project (to favor ease of
development), 

Re: [ros-dev] [ros-diffs] [cwittich] 66547: [WLANAPI] add stubs for WlanQueryInterface and WlanGetInterfaceCapability

[Christoph von Wittich]

ReactOS/include/psdk/wlanapi.h:27: error: 'PWLAN_OPCODE_VALUE_TYPE':
[v1_enum] attribute applied to non-enum type


-Ursprüngliche Nachricht-
Von: Ros-dev [mailto:ros-dev-boun...@reactos.org] Im Auftrag von Thomas
Faber
Gesendet: Dienstag, 3. März 2015 09:15
An: ros-dev@reactos.org
Betreff: Re: [ros-dev] [ros-diffs] [cwittich] 66547: [WLANAPI] add stubs for
WlanQueryInterface and WlanGetInterfaceCapability

On 2015-03-02 20:27, cwitt...@svn.reactos.org wrote:
 --- trunk/reactos/include/psdk/wlanapi.h  [iso-8859-1] (original)
 +++ trunk/reactos/include/psdk/wlanapi.h  [iso-8859-1] Mon Mar  2
19:27:45 2015
 @@ -24,7 +24,7 @@
  wlan_opcode_value_type_set_by_group_policy,
  wlan_opcode_value_type_set_by_user,
  wlan_opcode_value_type_invalid
 -} WLAN_OPCODE_VALUE_TYPE;
 +} WLAN_OPCODE_VALUE_TYPE; /* HACK: WIDL is broken,
*PWLAN_OPCODE_VALUE_TYPE; */
  
  typedef enum _WLAN_SECURABLE_OBJECT {
  wlan_secure_permit_list = 0,

What's broken, exactly? Let's see if we can get it fixed...

___
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

Re: [ros-dev] [ros-diffs] [cwittich] 63452: [bootdata] converthivecls.inf and hivedef.inf to UTF16LE fixes CORE-7614

[Christoph von Wittich]

Seems to work only with TSVN :/


-Ursprüngliche Nachricht-
Von: Ros-dev [mailto:ros-dev-boun...@reactos.org] Im Auftrag von Colin Finck
Gesendet: Montag, 26. Mai 2014 19:41
An: ros-dev@reactos.org
Betreff: Re: [ros-dev] [ros-diffs] [cwittich] 63452: [bootdata]
converthivecls.inf and hivedef.inf to UTF16LE fixes CORE-7614

Christoph von Wittich wrote:
 Did you notice the mime type I set?

text/plain;charset=UTF-16 looks cool, didn't know about this one.
Still, it doesn't make patching any better. I just had a try with
command-line SVN 1.7.9: Changing hivedef.inf a bit, doing svn diff 
diff.patch, reverting hivedef.inf again and trying svn patch diff.patch.
The resulting hivedef.inf was totally garbage.

With such bad UTF-16 support for basic tasks, I still don't consider this a
solution. Let's better stick to UTF-8 for these files and convert them to
UTF-16 on the fly. This also denotes the UTF-16 critical files in the build
files.

Matthias has written the utf16le tool for this years ago, it just needs a
simple rule in CMake. Would anybody volunteer?


- Colin

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


smime.p7s
Description: S/MIME cryptographic signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [cwittich] 63452: [bootdata] converthivecls.inf and hivedef.inf to UTF16LE fixes CORE-7614

[Christoph von Wittich]

Did you notice the mime type I set?

- Ursprüngliche Nachricht -
Von: Thomas Faber thomas.fa...@reactos.org
Gesendet: ‎26.‎05.‎2014 01:11
An: ros-dev@reactos.org ros-dev@reactos.org
Betreff: Re: [ros-dev] [ros-diffs] [cwittich] 63452: [bootdata] 
converthivecls.inf and hivedef.inf to UTF16LE fixes CORE-7614

This is not the right solution. SVN has terrible UTF-16 handling so we
should not convert these back to UTF-16.

https://jira.reactos.org/browse/CORE-7703
https://jira.reactos.org/browse/CORE-8221

On 2014-05-25 22:17, cwitt...@svn.reactos.org wrote:
 Author: cwittich
 Date: Sun May 25 20:17:25 2014
 New Revision: 63452
 
 URL: http://svn.reactos.org/svn/reactos?rev=63452view=rev
 Log:
 [bootdata]
 convert hivecls.inf and hivedef.inf to UTF16LE
 fixes CORE-7614
 
 Modified:
 trunk/reactos/boot/bootdata/hivecls.inf   (contents, props changed)
 trunk/reactos/boot/bootdata/hivedef.inf   (contents, props changed)
 


___
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

Re: [ros-dev] [ros-diffs] [cwittich] 63423: [shell32] revert one line of r63414

[Christoph von Wittich]

This should be send to wine then.

-Ursprüngliche Nachricht-
Von: Ros-dev [mailto:ros-dev-boun...@reactos.org] Im Auftrag von Thomas
Faber
Gesendet: Samstag, 24. Mai 2014 11:03
An: ros-dev@reactos.org
Betreff: Re: [ros-dev] [ros-diffs] [cwittich] 63423: [shell32] revert one
line of r63414

 --- trunk/reactos/dll/win32/shell32/shlexec.cpp   [iso-8859-1]
(original)
 +++ trunk/reactos/dll/win32/shell32/shlexec.cpp   [iso-8859-1] Fri May
23 17:14:39 2014
 @@ -459,7 +459,7 @@
  startup.dwFlags = STARTF_USESHOWWINDOW;
  startup.wShowWindow = psei-nShow;
  dwCreationFlags = CREATE_UNICODE_ENVIRONMENT;
 -if (!(psei-fMask  SEE_MASK_NO_CONSOLE))
 +if (psei-fMask  SEE_MASK_NO_CONSOLE)
  dwCreationFlags |= CREATE_NEW_CONSOLE;
  startup.lpTitle = (LPWSTR)(psei-fMask  (SEE_MASK_HASLINKNAME |
SEE_MASK_HASTITLE) ? psei-lpClass : NULL);


This is the opposite of what the documentation says?


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


smime.p7s
Description: S/MIME cryptographic signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [sir_richard] 45777: [NTOS]: Do the funny message (not really funny, my apologies) shenanigans after the system components have shutdown, and reset the display and call the

[Christoph von Wittich]

remove++

Am 03.03.2010 09:31, schrieb Ged Murphy:
 sir_rich...@svn.reactos.org wrote:
 
 Did you know the funny messages take up more storage space than an average 
 embedded micro-controller OS?
 
 I've never liked these and I think they should be removed.
 They aren't funny and I'm not 12 years old
 
 Ged.
 
 
 
 
 
 ___
 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

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.

[Christoph von Wittich]

I've seen patches to kvm to support sysexit - but they aren't in the 
currently release yet.


Btw. I just got

(hal\halx86\generic\bios.c:228) HAL: Trap0D while not in V86 mode

at the end of 2nd stage in vmware.

Christoph


Am 27.01.2010 09:36, schrieb Ged Murphy:
 sir_rich...@svn.reactos.org wrote


 ... (interesting that buildbot's QEMU does not support SYSENTER, as newer 
 versions do)...
  
 Buildbot doesn't use QEMU it uses KVM. I realise that KVM uses parts of QEMU, 
 but I don't know to what extent.
 Maybe this is the reason for the difference?

 Maybe one day we'll have a real operating system running our build machine 
 instead of linux ;)

 Ged.






 ___
 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

Re: [ros-dev] [ros-diffs] [hyperion] 44091: modified Makefile Give poor pefixup its own echo line modified ReactOS-amd64.rbuild modified ReactOS-arm.rbuild modified ReactOS-i386.rbuild Set global link

[Christoph von Wittich]

codeblocks backend is useless as codeblocks lacks lots of features 
required to build reactos

Ged Murphy schrieb:
 Not sure about codeblocks but I still use the msvc backend to generate all 
 the vcproj files.


 -Original Message-
 From: ros-diffs-boun...@reactos.org [mailto:ros-diffs-boun...@reactos.org] On 
 Behalf Of hyper...@svn.reactos.org
 Sent: 11 November 2009 03:41
 To: ros-di...@reactos.org
 Subject: [ros-diffs] [hyperion] 44091: modified Makefile Give poor pefixup 
 its own echo line modified ReactOS-amd64.rbuild modified ReactOS-arm.rbuild 
 modified ReactOS-i386.rbuild Set global linker flags globally Goodbye 
 NTOSKRNL_SHARED modified tools/rbuild/backe

 modified   tools/rbuild/backend/codeblocks/codeblocks.cpp
 modified   tools/rbuild/backend/msvc/vcprojmaker.cpp
Build fixes. I really want to delete these dead backends



 ___
 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

[ros-dev] testing on buildserver is broken

[Christoph von Wittich]

hangs with endless

ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!
(ARM³::MDLSUP:692) MDL PROBE FAILED!

___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev