At Wed, 5 Jun 2019 01:33:25 -0700 (PDT) Alexandru <
alexandr...@meshparts.de> wrote:
>
> Am Mittwoch, 5. Juni 2019 10:16:03 UTC+2 schrieb Alexandru:
> > Am Mittwoch, 5. Juni 2019 07:50:40 UTC+2 schrieb Alexandru:
> > > Am Mittwoch, 22. Mai 2019 10:25:08 UTC+2 schrieb Ralf Fassel:
> > > > * Harald Oehlmann <
wort...@yahoo.de>
> > > > | > You need
> > > > | >=20
> > > > | > _wfopen(FileName, L"rb, ccs=3DUNICODE")
> > > > | > ^
> > > > | > =20
> > > > | > (note the 'L' before the string constant).
> > > > | > _wfopen() expects all arguments being wchar_t's, the 'L' makes th=
> e
> > > > | > string constant one.
> > > > >
> > > > | Ok, thank you ! I thought, the "ccs=3DUNICODE" is for the contents,=
> not
> > > > | for the file path specification.
> > > >=20
> > > > It is indeed for the *contents* of the file!
> > > >=20
> > > > The 'L' is just to make the string "rb, ccs=3DUNICODE" a wchar_t* str=
> ing
> > > > instead of a char* string, so it fits the function signature of
> > > >=20
> > > > _wfopen(wchar_t*, wchar_t*).
> > > >=20
> > > > If you code
> > > > _wfopen(FileName, "rb, ccs=3DUNICODE")
> > > > without the 'L', you would call a
> > > >=20
> > > > _wfopen(wchar_t*, char*)
> > > >=20
> > > > instead (note the difference in the type of the second argument).
> > > >=20
> > > > R'
> > >=20
> > > On a Windows 7 system the checksum function crashes on simple files wit=
> hout special chars in the path. The app simply closes and the OS shows the =
> "app crashed" window.=20
> > >=20
> > > Before changing the way the path is send to C, the function worked.=20
> > >=20
> > > On Win 10 there is not problem.
> > >=20
> > > What could be the reason?
> >=20
> > Nope, the issue is caused by the way I compile the dll. Recently I change=
> d my machine and I'm sing mingw 64 bit. In the past I used mingw 32 bit. I =
> don't find this intallation anymore. It might also be that the Win 7 is 32 =
> bit and I compile on Win 10 64 bit. I'll try to compile on Win 7 32 bit...
>
> I must correct again: Both systems are 64 bit, the difference is win 7 to w=
> in 10. Somehow I must compile on win 7 in order to get a working dll for wi=
> n 7. Seems to be a incompatibility of win 7 with mingw compilations that ar=
> e done on win 10. No idea why...
This is SOP: *always* compile on the lowest version of the O/S you intend to
support. Virtually *ALL* system software (including O/S supplied shared
libraries/DLLs) is downward compatible: that is code compliled against version
X will run with version X+1, but [probably] won't run with version X-1.
There will likely to be cases where you need to compile both places -- usually
when the new version of the O/S completely replaces library foo will library
bar so code compiled against library foo won't run on the new system, but this
generally does not happen (usually the O/S will include a "legacy" library foo
to support older program).
>
--
Robert Heller --
978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services