June 2015 - Wine-Devel - list.winehq.org

Fw: Re: [PATCH] cmd: fix invalid "else if" execution (try2)

by Thomas Faller

Hello, these test failures weren't triggered by my patch. - Thomas Am 24.06.2015 um 22:23 schrieb Marvin: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=14664 > > Your paranoid android. > > > === wxppro (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === w2003std (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1368 (got 'value2', wanted '2set1endvalue1') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1369 (got 'C:\Documents and Settings\Administrator\My Documents\foobar\foodir2', wanted '@drive@@path(a)foobar\foodir3') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1370 (got 'value1', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1371 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1372 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === wvistau64 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > > === w8 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--------'', wanted ''--a------'@or_broken@'%~ai'') > > === wvistau64 (64 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > >

June 25, 2015

Re: ntdll: Randomize security cookie when available (try 3)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > + /* randomize security cookie */ > + > + if (IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG < nt->OptionalHeader.NumberOfRvaAndSizes && > + (pos = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG].VirtualAddress)) > + { > + IMAGE_LOAD_CONFIG_DIRECTORY *loadcfg = (IMAGE_LOAD_CONFIG_DIRECTORY *)(ptr + pos); > + ULONG_PTR *cookie = (ULONG_PTR *)loadcfg->SecurityCookie; > + > + srand( time( NULL ) ); > + *cookie = rand(); This won't be random at all. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2015

Re: When/how to build separate debug symbol files

by Marcus Meissner

On Wed, Jun 24, 2015 at 06:26:31PM -0500, Ken Thomases wrote: > Hi, > > I'm investigating how to best make Wine build and install debug symbol files on OS X. > > My understanding is that, on Linux, the distros usually provide a > separate package for a user to install Wine's debug symbols. From recent > work in dbghelp, I'm guessing such a package installs debug symbol files > next to the corresponding binary or in a .debug subdirectory next to it. > Is that correct? For SUSE we install the debuginfo in places like: /usr/lib/debug/usr/lib64/libusb-1.0.so.0.1.0.debug for e.g. the libusb 1.0 shared library. /usr/lib64/libusb-1.0.so.0.1.0 Other distros might do it differently. > How do packagers generate such separate debug symbol files? Is it > a special option (make target?) in Wine's build process? Or is it a > post-processing step after Wine is built and installed to a staging > directory? How does this interact with stripping during building for > the non-debug-symbol, normal Wine package? It is standard macro hidden in our RPM build process. It happens after the regular package "make install" is done. It extracts the debuginfo fully automatic, no packager attention required. Basically it does objcopy of the debug sections for all libraries and binaries, and afterwards it does "strip --strip-unneeded" The package build itself is not supposed to strip binaries. CIao, Marcus

June 25, 2015

Re: When/how to build separate debug symbol files

by Ken Thomases

On Jun 24, 2015, at 7:58 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > On Jun 24, 2015, at 5:26 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >> >> How do packagers generate such separate debug symbol files? > I think they either: > a) use split DWARF (-gsplit-dwarf option to GCC/Clang), which will give you *.dwo files; or > b) use objcopy(1) to extract the .debug_* sections from the final binaries into *.debug files. > > I suspect it’s the second one; split DWARF (aka DWARF Fission) is relatively new, so I don’t think it’s widely used yet. OK. Do they get any help in applying objcopy to Wine's binaries? That is, is there anything in Wine's build system into which they hook? Or do they just need to manually identify the binaries somehow? (Not saying it's necessarily hard, just wondering what the right way to do it is.) >> How does this interact with stripping during building for the non-debug-symbol, normal Wine package? > Wine doesn’t run strip(1) until install time. Yup. I was aware of that. > This gives packagers time to objcopy(1) the DWARF data before it’s stripped away. I was thinking that the "make install" step would both be the opportunity to apply objcopy and also be a way to identify the files on which to apply it. Basically, anything on which INSTALL_PROGRAM is used. They might even do it with a cleverly-specified STRIP command. >> The dsymutil depends on references from the linked binary to the original object files from which it was created. Those references are in the STABS info. So, it has to be invoked 1) at a point where those object files are accessible, and 2) before the binary has been stripped of the necessary references. > First, I’ll tell you that, under certain circumstances, it’s possible to get GCC or Clang to invoke dsymutil(1) for you. I haven’t yet completely worked out what those circumstances are—so far, I know that it will do this if you compile and link in one step, but I don’t know how to get it to do this automatically when linking objects with a __DWARF segment. OK, interesting, but I don't think I want to rely on that. I think it's best to figure out when and how to call dsymutil and do that explicitly from Wine's build system. > The other thing I’ll tell you is that, since strip(1) isn’t run until install time (and, in fact, probably won’t be run at all on Mac OS since we often use BSD install(1) there), you should be able to run dsymutil(1) at any time up to ‘make install’. Yes, sure, I can do it manually (both deciding to do it and figuring out what to do it to). I'm hoping to find the right way to automate it. Regarding whether stripping is done on OS X, Wine seems to use GNU install (if I've properly understood). Wine ships tools/install-sh and uses that. However, it seems that one must specify INSTALL_PROGRAM_FLAGS=-s in order to make it actually try to strip. A simple "make install" doesn't by default. And, then, OS X's strip throws errors when used without options, so you have to specify STRIP="strip -x". >> A problem that may be unique to OS X is how to support debugging when running Wine build from source, either run from the build tree or installed by the user. Since the debug information isn't easily accessible unless the separate dsymutil step was done, we may want to do it at link time, not just at install time. Unfortunately, that largely defeats the point of separating out debug linking from normal linking, which was to save time and disk space. > It’s actually possible to read the DWARF data out of the object files (if they’re still around). Both GDB and LLDB do this in the absence of a dSYM companion bundle/file. This is easier said than done, though. If you go this route, you’ll need to relocate the object files’ DWARF data (basically, doing what dsymutil(1) does) before making them available to clients. Yes, that's what I meant by "isn't easily accessible". ;) Not impossible, just not easy. Thanks for your input, Ken

June 25, 2015

Re: When/how to build separate debug symbol files

by Charles Davis

> On Jun 24, 2015, at 5:26 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > Hi, > > I'm investigating how to best make Wine build and install debug symbol files on OS X. > > My understanding is that, on Linux, the distros usually provide a separate package for a user to install Wine's debug symbols. From recent work in dbghelp, I'm guessing such a package installs debug symbol files next to the corresponding binary or in a .debug subdirectory next to it. Is that correct? > > How do packagers generate such separate debug symbol files? I think they either: a) use split DWARF (-gsplit-dwarf option to GCC/Clang), which will give you *.dwo files; or b) use objcopy(1) to extract the .debug_* sections from the final binaries into *.debug files. I suspect it’s the second one; split DWARF (aka DWARF Fission) is relatively new, so I don’t think it’s widely used yet. > How does this interact with stripping during building for the non-debug-symbol, normal Wine package? Wine doesn’t run strip(1) until install time. That’s why we set the STRIPPROG environment variable: if install(1) is GNU install, it’ll pick that up and run the specified strip(1) program on the installed copies of any binaries. This gives packagers time to objcopy(1) the DWARF data before it’s stripped away. > > The dsymutil depends on references from the linked binary to the original object files from which it was created. Those references are in the STABS info. So, it has to be invoked 1) at a point where those object files are accessible, and 2) before the binary has been stripped of the necessary references. First, I’ll tell you that, under certain circumstances, it’s possible to get GCC or Clang to invoke dsymutil(1) for you. I haven’t yet completely worked out what those circumstances are—so far, I know that it will do this if you compile and link in one step, but I don’t know how to get it to do this automatically when linking objects with a __DWARF segment. The other thing I’ll tell you is that, since strip(1) isn’t run until install time (and, in fact, probably won’t be run at all on Mac OS since we often use BSD install(1) there), you should be able to run dsymutil(1) at any time up to ‘make install’. > A problem that may be unique to OS X is how to support debugging when running Wine build from source, either run from the build tree or installed by the user. Since the debug information isn't easily accessible unless the separate dsymutil step was done, we may want to do it at link time, not just at install time. Unfortunately, that largely defeats the point of separating out debug linking from normal linking, which was to save time and disk space. It’s actually possible to read the DWARF data out of the object files (if they’re still around). Both GDB and LLDB do this in the absence of a dSYM companion bundle/file. This is easier said than done, though. If you go this route, you’ll need to relocate the object files’ DWARF data (basically, doing what dsymutil(1) does) before making them available to clients. Chip

June 25, 2015

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)

by Kyle Auble

On 06/24/2015 08:18 AM, Austin English wrote: > > On Jun 21, 2015 2:58 AM, "Kyle Auble" <kyle.auble(a)zoho.com > <mailto:kyle.auble(a)zoho.com>> wrote: > > In the end though, beyond just adding more comments to the bottom of > > the page, I couldn't figure out how anyone earns the rights necessary > > to fix tags or recategorize bugs. I even tried emailing the Bugzilla > > admin to ask but never heard back. Honestly, beyond some of the > > developers and site admins, whom I assume have elevated rights across > > WineHQ, I still don't know who processes the bug reports. > > I didn't realize there was a Bugzilla admin email alias, I've asked > Jeremy Newman to add me, so now someone active is watching it :) > Cool, and I just realized that it was Jeremy Newman I had been talking to when I was working on the webpage (it's been a while). Either way, to both Jeremy-s and everyone else, keep up the good work. > > For future reference though, if in doubt, email wine-devel or ask on > #winehackers. > Will do, and to be fair, unless it's a critical life goal, I'm not the most persistent person so I probably should have asked around more. Quick question about #winehackers etiquette: if I can't be on all the time and want to use an IRC bouncer, is it ok to spread out conversations over time? Or is that seen as rude; should I only keep conversations going so long as they're relatively active? > > (If you still need permission to triage, send me an email, though I > won't have a chance to do so for a few days, currently traveling.) > I'm going through a move right now, but when things are more stable, I might email you then. I also just realized that even without triage permissions, maybe I could have still emailed to check in with reporters about abandoned bugs (I don't remember if standard rights let you email other users). First though, I might try to get a good grip on building and linking multiarch wine, then see if I can streamline it at all (I know I complained about that in particular, but I can get things done if I focus so I should code, not kvetch). - Kyle

June 25, 2015

Re: Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.

by Peter Dolding

On Wed, Jun 24, 2015 at 9:42 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > In addition to being the popular Win32/Win64 PE executable format, > .exe files can also be DOS 16 bit ME or NE executables, OS/2 32 bit LE > executables, Win16 NE executables, as well as contain .NET code in the > PE format. It's thus not even clear that Wine should open .exe files, > as at least Mono and DOSBOX are better candidates for some of them. This is a reason todo why I am suggesting. By adding a exe.mainfest with wine data or exe.winemainfest file marks the application as clearly to be opened by wine. Technically Win32/Win64, Win16 NE Dos ME or NE or .Net code could have to be opened with wine. Now out of these list Dos ME or NE and .Net at times should not be run as wine and some must be run in wine or you break programs. There is no marker. Yes part of the wine data in a manifest will have to include flag this is not wine. Also just using MINE type does not tell you want WINEPREFIX the application owns to. > Additionally on the desktop we can use wine.desktop to open .exe files > via MIME type match without needing root permissions to set this up, > so I am not sure why binfmt-misc is necessary. > The reason why binfmt-misc format is failing is it is only a MIME match. So the wine.desktop has all the same issues as binfmt-misc and a extra weakness. Part of the reason why binfmt-misc requires root to set it up is the fact it can assign permissions like file capabilities and LSM attributes from what is recorded on the .exe file. The.desktop solution cannot do this. The result of using wine.desktop and .desktop files instead of being operational with binfmt-misc is the use of CAP_NET_RAW and CAP_NET_BIND_SERVICE on the wineloader program instead of on the .exe files themselves. Yes setting up binfmt-misc requires root. But binfmt-misc is where non native Linux applications requiring Linux security permissions should start their execution path. I do not have windows to test with and I need someone to test is I can place non Microsoft schema in a .mainfest file without risking major trouble. Or someone suggest another way I can tag the executable so the executable can in fact be run the correct solution every single time. Really the MINE type usage by .desktop to run wine should disappear for Linux other than to tell the system to directly execute the exe. Even .desktop files to run programs under Linux should become super simple. Path to executable as enough. All the extra complexity in the .desktop files for Linux is a bug. Peter Dolding > > On Tue, Jun 23, 2015 at 8:44 AM, Peter Dolding <oiaohm(a)gmail.com> wrote: >> For binfmt-misc to be workable a few things need to be known. >> >> 1) What version of wine >> 2) What wineprefix >> 3) What setting overrides. >> >> None of these can be done by environmental vars because binfmt-misc >> might be directly executing the file. >> >> Windows compadiblity mode does not use the registry like wine does. >> Instead it done in two horible halves. >> >> Half 1. The application manifest file. The mainfest file may be >> embedded in the .exe file or be .exe.mainfest >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh848036%28v=vs.85… >> Yes this is where you set what version of Windows application was >> designed to run with. So running XP mode on Windows 7 is here. >> >> Half 2. Application Compatilibity Database >> This is where it gets horible using shims on particular executables to >> make broken executables work. Also when this gets too large starts >> slowing windows down as it searching the database to make applications >> work. Yes reason some old applications don't work with Windows 10 >> that worked with 7 is that their entries were deleted from this >> database. >> >> To solve the problem I think we could get away with just Half the >> manifest can include library overrides and some windows configuration >> tweaks. But we have problems the include library information wine >> needs because of native and built-in libraries. Due to the fact wine >> is running on Linux and other OS's some of the configuration tweaks >> are going to be wine dependant. So we need another schema. >> >> >> http://wiki.winehq.org/UsefulRegistryKeys >> Because if Microsoft manifest would tolerate alien schema really >> everything under software\wine\appdefaults could be moved from the >> registry to the manifest. Advantage 1 this can be write protected >> per application and second advantage possibility of embedding in the >> exe itself. >> >> >> Also for binfmt-misc support have in the schema the means to record >> wineprefix and wine to use. So the program starting wine >> applications by binfmt-misc looks for either a mainfest or a >> winemainfest file in the same directory as the exe to see what wine >> environment the application should be running with. If there is no >> configured environment possibly ask user what wineprefix they do what >> to run the application with. >> >> What I do not know is if Microsoft application manifest file will >> tolerate an alien schema. Don't have different versions of Windows >> to test if Microsoft application manifest with a alien schema parts >> works or just causes windows to throw error or just results in the >> manifest being complete ignored. >> >> Now if Microsoft application manifest will not tolerate alien I have >> to ask would creating own own like exe.winemainfest be acceptable. >> >> I do hope Microsoft application manifest will tolerate alien because >> it would be really useful to have applications with a manifest a >> values saying what versions of wine they were tested with by the >> maker. Currently there is no way for a application vendor to record >> in the application they tested with wine. >> >> A lot of ways putting what shim modifications the application need in >> the manifest would also remove having to look up a huge database. >> >> Getting binfmt-misc working also will remove having to use setcap on >> wineloader instead of the .exe. Also would make if someone set a >> capicapity limitation by logind not break every wine application just >> because a few application where needing privileged operation.. >> >> So this alteration would be getting closer to how Windows does stuff >> and in the process making Linux integration better. >> >> Peter Dolding >> >>

June 25, 2015

When/how to build separate debug symbol files

by Ken Thomases

Hi, I'm investigating how to best make Wine build and install debug symbol files on OS X. My understanding is that, on Linux, the distros usually provide a separate package for a user to install Wine's debug symbols. From recent work in dbghelp, I'm guessing such a package installs debug symbol files next to the corresponding binary or in a .debug subdirectory next to it. Is that correct? How do packagers generate such separate debug symbol files? Is it a special option (make target?) in Wine's build process? Or is it a post-processing step after Wine is built and installed to a staging directory? How does this interact with stripping during building for the non-debug-symbol, normal Wine package? For what it's worth, I'm working on make dbghelp support DWARF-2 debug info on OS X <https://bugs.winehq.org/show_bug.cgi?id=22384>. On OS X, the normal link step does not transfer the DWARF-2 debug info from the object files to the file binary. Rather, you have to execute a separate command, dsymutil, to "link" the debug info, but that ends up in a separate file, not the binary. So, the first part is figuring out when to invoke dsymutil and where to put the debug symbol file. The second part is having dbghelp find that debug symbol file. I think I have a handle on the second part. The first part is what I'm trying to figure out. The dsymutil depends on references from the linked binary to the original object files from which it was created. Those references are in the STABS info. So, it has to be invoked 1) at a point where those object files are accessible, and 2) before the binary has been stripped of the necessary references. A problem that may be unique to OS X is how to support debugging when running Wine build from source, either run from the build tree or installed by the user. Since the debug information isn't easily accessible unless the separate dsymutil step was done, we may want to do it at link time, not just at install time. Unfortunately, that largely defeats the point of separating out debug linking from normal linking, which was to save time and disk space. Thanks, Ken

June 24, 2015

Re: d3dcompiler: Share the source with d3dcompiler_46

by Matteo Bruni

2015-06-24 12:15 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > diff --git a/dlls/d3dcompiler_46/Makefile.in b/dlls/d3dcompiler_46/Makefile.in > index 08c5145..41c98f7 100644 > --- a/dlls/d3dcompiler_46/Makefile.in > +++ b/dlls/d3dcompiler_46/Makefile.in > @@ -1,6 +1,24 @@ > MODULE = d3dcompiler_46.dll > +IMPORTS = dxguid uuid > +EXTRALIBS = $(LIBWPP) > +EXTRADEFS = -D_D3DCOMPILER_VER=46 That define isn't used yet, right? I guess you can keep it around but maybe call it D3D_COMPILER_VERSION since there is such a define in recent d3dcompiler.h from the SDK. Or just drop it for the time being and reintroduce it when there will be a need to distinguish the version we're compiling for from the shared code. Otherwise it looks fine to me. Maybe rename d3dcompiler_43_main.c to just main.c? That change can be a separate patch.

June 24, 2015

Re: [PATCH] cmd: fix invalid "else if" execution (try2)

by Thomas Faller

Hello, these test failures weren't triggered by my patch. - Thomas Am 24.06.2015 um 22:23 schrieb Marvin: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=14664 > > Your paranoid android. > > > === wxppro (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\winetest\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === w2003std (32 bit) === > [..] > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1368 (got 'value2', wanted '2set1endvalue1') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1369 (got 'C:\Documents and Settings\Administrator\My Documents\foobar\foodir2', wanted '@drive@@path(a)foobar\foodir3') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1370 (got 'value1', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1371 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1372 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1373 (got '--- Extra endlocal in called batch', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1374 (got '--- Extra endlocal in called batch', wanted '@drive@@path(a)foobar') > batch.c:312: Test failed: unexpected char 0x46 position 0 in line 1376 (got 'Finished:', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x76 position 0 in line 1379 (got 'value1', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x43 position 0 in line 1380 (got 'C:\Documents and Settings\Administrator\My Documents\foobar', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1381 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'Finished:') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1382 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1383 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar\foodir2') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1384 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted 'value1') > batch.c:312: Test failed: unexpected char 0x2d position 0 in line 1385 (got '--- endlocal in called function rather than batch pgm is ineffective', wanted '@drive@@path(a)foobar') > > === wvistau64 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > > === w8 (32 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--------'', wanted ''--a------'@or_broken@'%~ai'') > > === wvistau64 (64 bit) === > batch.c:312: Test failed: unexpected char 0x27 position 0 in line 318 (got ''--a--c---'', wanted ''--a------'@or_broken@'%~ai'') > >

June 24, 2015