Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type Issues #13

Open
SynSnipe opened this issue Mar 6, 2021 · 4 comments
Open

Type Issues #13

SynSnipe opened this issue Mar 6, 2021 · 4 comments

Comments

@SynSnipe
Copy link

SynSnipe commented Mar 6, 2021

Type Issues in Windows side of psutil. I assume something changed in winim but I am uncertain.
Linux compiles and runs without issues.

Nim Version

nim -v
Nim Compiler Version 1.4.4 [Windows: amd64]
Compiled at 2021-02-23
Copyright (c) 2006-2020 by Andreas Rumpf

active boot switches: -d:release

winim version

nimble install winim
Downloading https://github.com/khchen/winim using git
  Verifying dependencies for [email protected]
 Installing [email protected]
   Building winim/winim/winimx.exe using c backend
    Prompt: [email protected] already exists. Overwrite? [y/N]
    Answer: N

psutil version

nimble install psutil
Downloading https://github.com/juancarlospaco/psutil-nim using git
  Verifying dependencies for [email protected]
 Installing [email protected]
    Prompt: [email protected] already exists. Overwrite? [y/N]
    Answer: N

compilation output

C:\Users\user\processlist>nim c mytest.nim
Hint: used config file 'C:\nim-1.4.4\config\nim.cfg' [Conf]
Hint: used config file 'C:\nim-1.4.4\config\config.nims' [Conf]
...................................................................................................
C:\Users\user\.nimble\pkgs\psutil-0.6.0\psutil\psutil_windows.nim(151, 30) Error: type mismatch: got <HANDLE, HMODULE, array[0..259, TCHAR], DWORD>
but expected one of:
proc GetModuleBaseName(hProcess: HANDLE; hModule: HMODULE; lpBaseName: LPWSTR;
                       nSize: DWORD): DWORD
  first type mismatch at position: 3
  required type for lpBaseName: LPWSTR
  but expression 'szProcessName' is of type: array[0..259, TCHAR]

expression: GetModuleBaseName(hProcess, hMod, szProcessName, cast[DWORD](len(szProcessName)))

The issues are not limited to this proc. I tried to run down my list of issues that I had as a result of trying to create a windows process list. Unfortunately the type issues go a bit deeper than I understand at this point.

@SynSnipe
Copy link
Author

SynSnipe commented Mar 6, 2021

Simple Code that I was trying to compile...

import psutil

proc main : void =
    echo "psutil test"
    let pidList = pids()
    echo $pidList

when isMainModule:
    main()

Again works on Linux but not on Windows.

@johnscillieri
Copy link
Owner

Sorry for the issue, i'll take a look soon-ish and provide an update.

@IvanScheers
Copy link

Hi, I'm having the same issue.

@IvanScheers
Copy link

I know how to solve the issue, and did it in the code on my PC, but don't know how to edit the code here, otherwise I would.

Anyway:

In psutil_windows.nim, everwhere you get a LPWSTR error the var should be declared as wstring, for a LPSTR error, declare the var as cstring. These variables were declared as TCHAR or char arrays
Example code:

##### var szProcessName: array[MAX_PATH, TCHAR]
    var szProcessName: wstring

##### var filename: array[MAX_PATH, char]
    var filename: cstring

##### var wcUser: array[512, TCHAR]
##### var wcDomain: array[512, TCHAR]
    var wcUser: wstring
    var wcDomain: wstring

It is in several places in the code that the declarations should be changed. It got broken because of a change in winim.

BTW pid_names() doesn't work, it returns a seq with PIDs and a seq with empty strings. I don't need that, so did not check why.

Mind that process_exists() is case sensitive ! If you want it case insensitive find the code and change to

if name.toLowerAscii() == processName.toLowerAscii():
            exists = true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants